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Preface 


This book presents one view of the world. It’s a survey of how to 
connect computers and other devices together to form a large, coherent 
network. The book focuses on DEC computers, but the focus is on how 
to use DEC computers in combination with a wide variety of other 
resources. 

Part 1 is an introduction to networks and architectures. This intro- 
ductory chapter provides a first glimpse of many of the concepts found 
throughout the book. 

Part 2 begins with a survey of the architectures that DEC has 
developed to connect computers together. Several different architec- 
tures coexist to provide different types of functionality in the network. 
The Digital Network Architecture is the primary architecture used for 
DECnet products. Specialized architectures are used for Clusters, the 
Local Area Transport, and maintenance operations. 

Part 3 shows how the DEC architectures are implemented into net- 
works. Local area networks and wide area networks are considered in 
turn. The final chapter discusses how the DECnet software is imple- 
mented and managed. 

Part 4 discusses a variety of other networking architectures. SNA 
and TCP/IP provide connections to the IBM, government, and Unix 
computing environments. OSI is discussed in great detail because of 
its central role in DNA Phase V. 

Part 5 of the book is a discussion of two very sophisticated protocols 
that are used to provide a full-featured graphics user interface in a 
networked environment. The X Windows System and Postscript allow 
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the full power of the underlying network to be used in a workstation 
environment. 

An understanding of the different architectures and their implemen- 
tation provides a valuable perspective for those who use networks. 
This book tries to provide a survey of the options available and some 
of their implications. As such it provides a starting point. Sugges- 
tions for further reading accompany each chapter for those desiring a 
more in-depth examination of selected topics. 
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Chapter 


Introduction: Networks and 
Architectures 


This is a book about networks and architectures. An architecture, like 
a building architecture, is a plan. If each of the components of an 
architecture is built according to the plan, they will work together. 
Simply put, a computer architecture is a way of making many in- 
dividual components work together as a system. 

Network architectures are just one of many different kinds of ar- 
chitectures. A computer, such as a VAX, has an architecture. The 
architecture details how the components of a CPU will function. Disk 
drives might also have an architecture. DEC’s Digital Storage Ar- 
chitecture details how disk drives and disk controllers work together. 

The network architecture begins with a complete computer system 
and says how these computers will communicate. The computer 
doesn’t have to be a general-purpose machine like a VAX, however. 
Dedicated computers, known as servers, also play a part in distributed 
network architectures like those discussed in this book. 

A distributed network means that different computers on the net- 
work specialize in different tasks. One computer, known as a terminal 
server, might specialize in communicating with terminals. Another 
computer, known as a print server, might specialize in laser printing 
services. Finally, a general-purpose computer like a VAX would spe- 
cialize in computation such as a database management system. All of 
these computers work together in a transparent fashion. How they 
work together is the subject of this book. 
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Fig. 1-1 ISO reference model. 


Layered Architectures: The ISO Reference Model 


A computer network is a complex system. The goal of the architecture 
is to hide that complexity from the user of the network. The user 
wants services—printing, computation, remote access to data, remote 
access to systems, messaging, or any of the other myriad services 
available in a modern computer network. 

The goal is thus a transparent network. Once the architecture is in 
place and implemented, the network should fade into the background. 
A user can ask for data without knowing its location. The fact that a 
network goes and gets the data should be irrelevant to the user. The 
user iS more interested in the semantics of the data—what it means 
and what to do with it. The procedural aspects of the data should be 
hidden. 

This transparent access to network services is accomplished by 
dividing the tasks of the network into a series of layers. Each layer 
accomplishes a specific set of tasks, which are then offered as a service 
to the user of that layer. How those tasks are accomplished are hid- 
den from the service user. The service provider transparently ac- 
complishes the given task. 

The International Standards Organization (ISO) reference model is 
the most widely accepted layered architecture for a computer network. 
Figure 1-1 shows the different layers in the ISO reference model. 
There are two characteristics to this model: 
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Fig. 1-2 Peer-to-peer communications. 


a Each layer communicates with its peer on another node using a 
protocol. 

ws Each layer presents a rigorously defined set of services to the layer 
on top of it. 


This is a layered architecture in that each layer has a specific set of 
tasks that it accomplishes. That layer then presents a set of services 
to the node on top. For example, the network layer is responsible for 
getting data to another node on the network. The service it presents 
to the transport layer is the delivery of data to a node. 

Once data gets to a node, the transport layer is responsible for 
delivering that data to a specific user. The transport layer thus per- 
forms the service of delivery of data to a user. The transport layer 
will use the services of the network layer to get the data to the next 
node. Figure 1-2 illustrates these peer to peer protocols. 

Peer-to-peer protocols are used to communicate between one in- 
stance of a layer and another instance on another node. A peer-to 
peer-protocol for the transport layer would indicate that the following 
information was meant for a specific user. Following the user address, 
known as a header, is a set of data. 
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The transport layer would take the incoming message, strip off the 
header, and then hand the user data off to the user of the transport 
service. 

Likewise, when the transport service has prepared a message, con- 
sisting of a header and data, it hands that information down to the 
network layer. The network layer treats the whole message as user 
data and appends its own header to the message. That header would 
indicate which node of the network it goes to. 

At the receiving end, the network layer would strip off the network 
header and hand the data up to the transport layer. The transport 
layer would strip off the transport header and hand the data up to the 
session layer, and so on. 


Lower Layers: Networks and Subnetworks 


The bottom of three layers of the ISO reference model are the lower 
layer services. These deliver data from one node on the network to 
another. To the user of the network layer, the topology of that net- 
work is masked. 

At the bottom of the architecture is the physical layer of a network. 
The responsibility of the physical layer is to transmit a series of bits 
over a wire. The fact that the bits may eventually go to different 
nodes or to different users is not the concern of this layer. 

The data link layer uses that service to send frames of data across a 
subnetwork. A frame consists of several bytes of data with a header. 
The header indicates the address of the receiving node. As can be 
seen, it is possible for several nodes to all access the same physical 
medium. It is the responsibility of the data link layer to deliver data 
to the appropriate user of the medium. 

An example of a combination of data link and physical layers is the 
Ethernet local area network (LAN) standard. Ethernet allows up to 
1024 nodes to share a single logical wire. The term “logical wire” indi- 
cates that the actual physical topology may consist of several seg- 
ments of wire connected together. To the user of the Ethernet, how- 
ever, all nodes look as though they are on one piece of wire and are 
directly accessible. 

Ethernet is an example of a subnetwork. A subnetwork allows data 
to be delivered directly to any node connected to the subnetwork. No 
routing decisions need be made. The header is added to the data and 
it is sent out. The subnetwork sends the data along to its destination. 

Other subnetwork technologies examined in this book are X.25 and 
ISDN. They allow data to be delivered in a wide area environment. 
Both X.25 and ISDN are connection oriented subnetwork services, 
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Fig. 1-3 Intermediate and end nodes. 


meaning that the user must first set up a virtual circuit to their des- 
tination. How to get to that destination, however, is masked from the 
user. 

The network layer is responsible for interconnecting subnetworks 
together and making routing decisions. If data must go through 
several different subnetworks, the network must decide which subnet- 
work is on the path to the eventual destination. 

A packet may go through several intermediate nodes before it 
reaches its eventual destination. The network layer is responsible for 
finding each of the nodes along a path to the end destination. The 
network layer is also responsible for adapting to changes in the topol- 
ogy of the network. Users of the network service do not concern them- 
selves with the fact that a packet may go through intermediate nodes. 

Figure 1-3 illustrates how intermediate nodes serve as a relay. A 
packet goes down the protocol stack, then back up the protocol stack 
at the intermediate node. Only when the packet reaches its final des- 
tination does it go up to the peer transport layer entity. 

While the topology of a subnetwork is hidden from the network ar- 
chitecture, the topology at the network layer is quite important. Up- 
date messages are periodically sent between all the different routing 
nodes on the network to keep them informed of any changes in the 
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topology. A change in the topology might be a new subnetwork or a 
new node or the failure of an existing component. 


Upper Layers: Users and Services 


Once data has gone through the network layer, the topology of the 
underlying network is hidden from users. The next two layers are 
responsible for farming out a stream of data to different users. 

The transport layer is responsible for providing reliable end to end 
communications. This is accomplished by assigning a logical circuit to 
each user of the transport layer. All data received is tagged with the 
number of this logical circuit. The transport layer is able to multiplex 
data from many different users and present a single stream-oriented 
interface to the network layer. 

In addition to the multiplexing function, the transport layer is 
responsible for reliable communications. All data received is broken 
up into packets and sent down to the network layer. Each packet is 
numbered. At the destination end, the transport layer examines each 
packet received to see if any are missing. If they are, it sends a mes- 
sage to its peer transport entity at the source end and requests 
retransmission of that particular packet. 

The user of the transport layer is thus assured of reliable end to end 
communications. The next layer, the session layer, is the interface to 
the operating system. When a new connection request is received, it 
is up to the session layer to validate that request. If the request is 
allowed, the session layer then activates the required service. 

Services are the real aim of the network. Services can include 
remote data access, remote printing, network-based electronic mail, 
Videotex, and a host of other functions. A service is performed by two 
applications communicating with each other. 

For two applications to communicate with each other, they have to 
agree on a common representation for data. Even a simple concept 
such as an integer is represented in different ways on different 
vendor’s machines. 

More complex objects, such as a file or a document or a graphic 
image, are also represented in different ways. It is the responsibility 
of the presentation layer to represent information in a machine-inde- 
pendent fashion. 

While the presentation layer is concerned with the representation of 
information, the application layer is responsible for the semantics of 
that information. The command “send a mail message” is an example 
of a semantic construct. How that mail message is represented would 
then be the responsibility of the presentation layer. 
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Multiple Architectures in Networks 


The abstract concepts in the ISO reference model have been imple- 
mented into a variety of specific architectures. Some of the architec- 
tures are general-purpose architectures meant to address a variety of 
needs. IBM’s System Network Architecture (SNA) or DEC’s Digital 
Network Architecture (DNA) are two examples of general purpose ar- 
chitectures. 

Other architectures are specialized. DEC’s Local Area Transport 
Architecture, for example, only deals with how terminal servers talk to 
hosts on an Ethernet. The purpose of this book is twofold: 


ws To illustrate the different architectures and their different functions 

a To show how the architectures are implemented in various physical 
media, on different hardware platforms, and in different software 
packages 


The book begins by talking about DEC network architectures. Next, 
it will talk about how to implement those architectures. In Part 4, a 
variety of other architectures are presented. 


Digital Network Architecture 


There are several DEC architectures. The most general network ar- 
chitecture is the Digital Network Architecture. DECnet consists of a 
series of DEC products that conform to the DNA architecture 
specifications. Figure 1-4 shows the layers of the DNA protocol stack. 

DNA is able to use three different subnetwork technologies. The 
Digital Data Communications Message Protocol is an example of a 
traditional data link protocol. DDCMP is used to form a point-to-point 
link between two computers. The physical medium used by DDCMP 
could be a simple RS-232-C cable or could consist of a satellite, 
microwave, or other wide area communications link. 

Another subnetwork technology is Ethernet. Ethernet consists of 
data and physical link protocols. To the DNA routing layer, the 
Ethernet topology looks like a single wire with many nodes on it. As 
we will see in the local area network chapter, this topology can actual- 
ly be quite complex. 

Ethernet is used by many other architectures. An important char- 
acteristic of Ethernet is that many users can coexist on the medium. 
The DNA routing layer is one of those users, but TCP/IP or LAT or 
other architectures will also be present on the same data link. 
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Fig. 1-4 Digital Network Architecture. 


A third subnetwork technology supported by DNA is the X.25 stand- 
ard. X.25 is a packet-switched data communications architecture. 
Again, DNA may share X.25 facilities with other users. 

The routing layer of DNA, which corresponds to the ISO network 
layer, is responsible for taking packets of data and deciding which 
data link the packet should travel on. A DNA network can have a 
highly complex topology with up to 63,000 computers. The respon- 
sibility of the routing layer is to know what that topology is and to 
stay abreast of any changes in the topology caused by node or line 
failures. 

The next two layers of DNA are the end-to-end communications and 
session layers. End-to-end communications is identical to the ISO 
transport layer. The session provides several important functions. 
First, it validates incoming connection requests. Second, it activates 
the appropriate service for a user. If a connection request comes in for 
an interactive log-in, for example, the session layer would activate the 
virtual terminal service. 

Third, the session layer provides a node name to address mapping 
service. Nodes, to users, have names like “MYVAX” or “GRAPHICS” 
or “DATABASE.” The session layer turns those logical names into 
DECnet addresses. 

Services in DNA fall into two categories: 


s Network management services 
s Network applications 


Network management services are a set of programs and protocols 
used to manage the network. These services use the facilities of the 
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network to exchange data on the current state of nodes, lines, and 
other network components. A variety of different user interfaces are 
present that can show the status of the network or historical utiliza- 
tion or indicators of activity. 

Network applications are the real reason we have this network. Ap- 
plications are services that users will see. An example of an applica- 
tion is the virtual terminal service. This service allows any user on 
any node of the network to log into any other node on the network. 

The role of the virtual terminal service is to mask the remote access 
from software packages. To the software package, there is no distinc- 
tion between a remote user and a local user. This means that the 
software does not have to be rewritten because of remote access. 

Other services allow remote access to data on the network. The 
Data Access Protocols (DAP) are a set of services that allow a user to 
access any file on the network, subject to security restrictions. Other 
data access protocols, such as the Distributed File Service, allow data 
on the network to appear as though it were local. Files anywhere on 
the network appear as though they were on the local disk drive. DFS 
provides a network-transparent access to data. This means that no 
matter which node a user logs onto, that user will always see the 
same files. 

Many other services will be examined in this book. Several mes- 
sage-handling protocols in DNA allow mail messages to be exchanged. 
Other protocols have been defined for Videotex and for computer con- 
ferencing. 


Other DEC architectures 


DNA services have the important characteristic of functioning on any 
node of a DECnet. The nodes can be remote using wide area network- 
ing links. Because of the general nature of the Digital Network Ar- 
chitecture, there are instances where performance is sacrificed for 
flexibility. 

Several other special-purpose architectures are meant to address 
highly specific functions. An example of this is the Maintenance 
Operations Protocol shown in Figure 1-5. Most services in DNA have 
to go through the protocol stack, including the session, end-to-end 
communications, and routing layers. MOP is a direct user of the data 
link layers, usually the Ethernet. 

Because MOP uses the Ethernet directly, it is a very simple 
protocol. This simple protocol can be implemented in a node’s read- 
only memory (ROM), whereas DNA is too complex to fit into the 
limited space available in ROM. MOP is thus used when a node is 
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Fig. 1-5 Local Area Transport Architecture. 


turned on as a protocol for fetching an operating system over the net- 
work. MOP allows for diskless nodes. 

Diskless nodes save money because expensive disk drives do not 
have to be furnished for specialized equipment. Diskless nodes also 
simplify system administration because software is stored in a central 
location. A device that uses the MOP protocols is a MicroVAX 2000. 
The MicroVAX 2000 is a general-purpose VAX computer, without a 
disk drive. The VMS operating system is stored on another system 
and downline loaded when the MicroVAX is turned on. 

Other diskless nodes are special-purpose computers. A terminal 
server is a dedicated computer that does nothing but handle terminal 
traffic. When a terminal server is initialize, it uses the MOP protocols 
to broadcast an appeal for help over the Ethernet. A VAX would then 
send the terminal server its operating system. DEC uses the MOP 
protocols for terminal servers, print servers, communications servers, 
SNA gateways, and many other specialized devices. 

Another special purpose architecture is the Local Area Transport 
Architecture (LAT). Figure 1-6 shows the LAT protocol stack. LAT is 
used exclusively on an Ethernet and provides an efficient method of 
sending terminal traffic to a host. 

LAT is able to use a single Ethernet packet to send data for many 
different users to the same host. LAT establishes a virtual circuit to 
that host, then puts many slots of data into each packet. Notice that 
both the DNA routing layer and LAT may coexist on a single Ether- 
net. 

LAT has many other features oriented toward terminal applications. 
For example, every host that is able to accept LAT traffic periodically 
broadcasts the availability of a service that it offers. Several nodes 
can offer the same service. Each node that offers a service also peri- 
odically broadcasts a service rating. The terminal server is able to 
connect a user to the node with the best service rating. 


Introduction: Networks and Architectures 13 


Distributed} Connection) Distributed 
File System| Manager |Lock Manager 


System Communication Services 
ethernet | cpus 


Fig. 1-6 System Communication Architecture (SCA). 


A third architecture is the System Communications Architecture, 
also known as VAX Clusters. Figure 1-7 shows the SCA protocol 
stack. VAX Clusters allow several nodes to be joined into a closely 
coupled network. The System Communication Services is somewhat 
equivalent to the DNA routing layer—both offer internode communica- 
tions services. 

SCA is able to use two different data link layers. Ethernet has a 
bandwidth of 10 million bits per second (mbps). The Computer Inter- 
connect bus operates at 70 mbps. The CI bus is used to connect large 
VAX systems and a special-purpose computer called the Hierarchical 
Storage Controller (HSC). The HSC is used to connect high perfor- 
mance disk drives to a very intelligent disk controller. 

The main purpose of the cluster is to allow multiple computers to 
share disk drives at high speeds. The CI bus cluster provides 
memory-to-memory throughput rates between a VAX and an HSC of 2 
megabytes per second (Mbps). 

A Local Area VAX Cluster (LAVC) provides the same functionality, 
but over the Ethernet. HSC controllers cannot be connected to the 
Ethernet, so a general purpose VAX must provide disk services. 

In either the LAVC or CI bus environment, clusters offer a unified 
security and management domain for multiple VAX systems. They 
also offer highly concurrent access to data, using distributed lock and 
file managers. ‘This entire cluster is managed with an application 
called the Cluster Manager. 

While DNA provides access to data, the cluster does the same ser- 
vice in a tightly coupled fashion. The cluster is thus limited to 42 
nodes but provides higher performance and functionality. DNA 
provides lower performance but allows access to data anywhere on the 
DECnet, which can have up to 63,000 nodes. 
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Fig. 1-7 TCP/IP and the Network File System. 


On a single Ethernet, it is not unusual to see DECnet, clusters, and 
the Local Area Transport Architecture all providing services. The ser- 
vices vary in performance, functionality, and flexibility. The purpose 
of Part 2 of this book is to show the three major architectures and 
their components. Part 3 will illustrate how the architectures are im- 
plemented. 


TCP/IP and SNA 


Part 4 discusses other network architectures, beginning with TCP/IP 
and SNA. TCP/IP is an architecture used in a heterogeneous environ- 
ment consisting of many different vendors equipment. An addition to 
the TCP/IP protocol stack is the Network File System, developed by 
Sun Microsystems. Figure 1-8 shows the TCP/IP and NFS protocol 
stacks. 

TCP/IP is actually layers 3 and 4 of the ISO reference model. 
TCP/IP is able to use several subnetwork technologies, including 
Ethernet and token ring LANs. In addition, TCP/IP frequently uses 
X.25 for wide area networking links. 
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Fig. 1-8 MOP and the DNA routing layer. 


The Internet Protocols allow the different subnetworks to be con- 
nected together. IP thus operates at layer 3 of the ISO reference 
model. Two different transport layer protocols are offered. The 
Transmission Control Protocol (TCP) provides reliable end-to-end com- 
munications. An alternate transport mechanism is the User 
Datagram Protocol (UDP). UDP is more efficient than TCP but does 
not guarantee that data will be delivered. It is up to the user of UDP 
to discover that a particular packet, or datagram, was delivered out of 
sequence or not delivered. 

Built on top of the basic TCP/IP protocol suite are three applica- 
tions. TELNET provides a virtual terminal service. The File Transfer 
Protocol (FTP) allows files to be copied from one node to another. The 
Simple Mail Transfer Protocol (SMTP) allows mail messages to be ex- 
changed. 

All three of these basic services are direct users of the transport 
layer. This has several drawbacks. First, there is no general 
mechanism for interprocess communication over the network. This is 
a function usually found in the session layer. Second, there is no 
provision for different types of nodes to exchange data in a node-inde- 
pendent fashion. Each application must provide for data repre- 
sentation. This is usually a function of the presentation layer. 

Sun Microsystems developed a set of protocols that are referred to 
as the Network File System. Although NFS could be implemented on 
other transport mechanisms, it is usually implemented on top of 
TCP/IP. Over 250 vendors have NFS licenses and implementations. 

NFS begins by adding a Remote Procedure Call (RPC) mechanism 
on top of the transport layer. RPC allows a process on one node to 
communicate with a process on another node. RPC thus extends the 
memory of a single system to allow function calls over a network. 

The External Data Representation (XDR) is a presentation layer 
protocol. XDR consists of a series of filters that translate node-specific 
data representation into a machine-independent representation. XDR 
defines filters for simple data types such as integers and characters 
but also defines mechanisms for filtering complex data structures, 
such as packed arrays. 
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The Network File System is an application that uses the services of 
XDR, RPC, and the TCP/IP protocol stack. NFS allows a file system 
on a remote node to appear as though it were local. A similar service 
is offered in DNA as the Distributed File Service. Both services will 
be described in this book, and the reader will notice both similarities 
and differences between the two implementations. 

The Systems Network Architecture (SNA) is yet another general- 
purpose network architecture, used for connecting IBM computers 
together. The SNA chapter of this book will describe different 
methods for interconnecting SNA and DNA environments together. 
DEC provides a high level of interconnectivity to SNA environments. 


Open architectures: OSI and DECnet/OSI 


The last general-purpose network architecture that will be described is 
Open Systems Interconnect (OSI). OSI is an implementation of the 
ISO reference model. OSI is important for a variety of reasons. 

First, OSI is an open networking environment. The protocol 
specifications are very specific and were arrived at over many years by 
international standards committees. Because they are open stand- 
ards, many different vendors will be able to write to them. OSI offers 
the capability of both high functionality and a heterogeneous network- 
ing environment. | 

Second, DEC is adopting OSI for Phase V of the Digital Network 
Architecture. DECnet Phase V is known as DECnet/OSI. The DNA 
architecture described in Part 2 of this book will thus be gradually 
supplanted by the services and protocols described in Part 4. 

Third, OSI looks like it will work. The standards committees built 
OSI on top of existing technologies. In particular, existing subnet- 
working technologies are incorporated by reference into the OSI 
protocol stack. Figure 1-9 shows this protocol stack. 

The logical link control is a subnetwork access procedure that works 
with different local area network technologies. Specifically, the Logi- 
cal link control is able to send data out over Ethernet, token ring, and 
token bus networks. 

Another subnetwork technology is the Integrated Services Digital 
Network (ISDN). ISDN is described in Chapter 7 of this book. ISDN 
allows transparent access to high-bandwidth wide area data links. 
Other subnetworks are X.25 for packet switching and X.21 for circuit 
switching applications. 

Since different subnetworks offer different levels of functionality, 
the network layer of OSI is split into two pieces. The subnetwork 
dependent convergence functions are used to supplement the services 
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of the subnetwork and to provide any subnetwork-dependent services. 
For example, in X.25 a virtual circuit must first be established before 
a packet can be sent. Establishing that virtual circuit would be a 
subnetwork-dependent convergence function for X.25. 

The upper sublayer of the network layer provides the packet for- 
warding function. This function accepts a packet from one subnetwork 
and forwards it over another. The user of the network layer sees only 
end-to-end communication. 

There are many different applications in the OSI model. The ap- 
plications layer, like the network layer, is split into two pieces. The 
lower sublayer, the Common Application Service Elements (CASE) are 
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used to provide common services needed by all application entities. 
This sublayer allows an association between two entities to be formed. 

The services built on top of CASE range from file access (FTAM) to 
database access (the Remote Data Access Protocols). The Job Transfer 
and Manipulation (JTM) service allows a work order to be sent to 
many different nodes and jobs to be executed. A virtual terminal ser- 
vice allows many different kinds of terminal to log into different nodes 
of an OSI network. Chapter 12 describes a variety of these OSI ser- 
vices. 


Architectures and implementations 


While much of this book describes architectures, there is a strong 
focus on how those architectures are implemented into networks. Part 
3, in particular, is focused on this question. Chapter 6 looks at Local 
area networks and Chapter 7 looks at wide area networks. Chapter 8 
looks at the implementation of DNA on different operating systems 
and how different user interfaces are used to manage a multi-architec- 
ture network. 

In addition to Part 3, the rest of the book also examines how these 
networks are implemented. The chapters on TCP/IP and SNA, for ex- 
ample, look at a variety of hardware and software products used to 
connect to the architectures. 3 

It is important to remember that an architecture is a theory. The 
theory says that all equipment that conforms to the architecture will 
work together. Implementations of architectures are reality. Reality 
means that different vendors may have different versions of the ar- 
chitecture or different levels of performance. This book looks at many 
of these implementation issues, but it is important to remember that 
implementations change rapidly. The last section of this chapter 
makes a few suggestions on how to find and compare different 
products that implement these architectures. 


Services 


The real purpose of a network is a service. We don’t buy Ethernet 
cable to send packets of data between two nodes. We buy Ethernet 
cable because we want to send electronic mail or transfer files or log 
into a remote node. Throughout the book, a variety of applications are 
examined. Three particularly important types of applications are: 


a File and data access 
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= Messaging systems 
e Windows and workstations 


File and data access 


File and data access are one of the main reasons for installing a net- 
work. Many different protocols, such as the Distributed File Service 
in DNA and the Network File System are meant to address this issue. 


Protocol Architecture Chapter 
Data Access Protocol 


Distributed File Service 3 
Clusters 5 
Network File Service 9 
DSR 10 
FTAM 12 


Distributed data access can range from simple file copies to more 
sophisticated protocols that offer highly concurrent access to in- 
dividual records in files. The following chapters describe data access 
protocols: 


Messaging systems 


Chapter 14 has an extensive discussion of the X.400 protocols. X.400 
is an OSI application that defines a message handling system. DEC 
networks have always’ provided extensive message-handling 
capabilities. Following the general discussion of X.400, there is a dis- 
cussion of an important DEC architecture known as MAILBUS. 

MAILbus is a message-handling architecture that is able to work 
with many different message-handling systems and user interfaces. 
Gateways exist to X.400 message-handling environments, the TCP/IP 
SMTP system, and the IBM SNADS and PROFS office automation 
environments. Other gateways exist to public electronic mail 
providers such as MCI Mail. 

MAILbus, as its name implies, allows many different forms of mail 
messages to be exchanged. A single user interface, such as All-In- 
One, is able to send mail messages to a variety of different environ- 
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ments. In fact, through MCI Mail and Western Union’s Easylink, 
electronic mail can be printed out and delivered as a telegram or letter 
to users who have never seen a computer. 


Windows and Workstations 


Part 5 of this book has an extensive discussion of an important new 
set of protocols aimed at allowing many different computers to provide 
services to a single bit-mapped workstation. The X Windows System 
is a set of protocols developed at the Massachusetts Institute of Tech- 
nology to allow programs to share a workstation. X has been adopted 
by DEC as part of their DECwindows environment. 

DECwindows also includes standards for a common look and feel. 
With many different applications accessible over a network, there is a 
danger in overwhelming a user with many different styles of opera- 
tion. A common look and feel allows a user to interact with each com- 
puter program the same way. This means, for example, that menus 
always function the same way or that a HELP is always activated the 
same way. 

The last chapter of this book describes the PostScript imaging sys- 
tem. X allows different programs to coordinate their access to a com- 
mon workstation display. PostScript is an imaging system used to 
construct and manipulate bit maps. PostScript is device independent, 
which means that the information on a user’s screen will look exactly 
the same when it is printed. PostScript is an especially powerful im- 
aging system with graphics capabilities that allow application 
programmers to exploit the power of modern workstations. 

The network provides transparent access to data and computing 
resource. The windowing system coordinates these different programs 
on the user’s screen. PostScript allows the user’s screen to stop look- 
ing like an extension of a dumb terminal. PostScript allows the user 
interface to move toward a more sophisticated presentation style. 


What to do after you read this book 


This book is an introduction to a very complex world. Its purpose is to 
give the reader a flavor for the different architectures and implemen- 
tations that can be used with DEC computers. Serious readers should 
continue their research in a number of ways. 

First, readers should continue doing research on topics of interest. 
Each chapter of the book covers a fairly complex area. Suggestions for 
further reading are included for a more in-depth examination of topics. 
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Some of these suggestions are DEC manuals or architectures specifica- 
tions. Others are textbooks or other standard reference materials in 
the field. 

Second, readers should investigate specific products and implemen- 
tations. Throughout the book, specific examples are cited that il- 
lustrate some of the features available. These products are cited for 
illustration and not as a recommendation for purchase. The field 
changes too quickly to be that specific. 

Readers who are investigating purchase of products should consult 
the trade press and trade shows to find out which vendors are produc- 
ing products. These sources can help narrow a vast field down to a 
few potential choices. Then, those vendors should be called in to 
present technical details about their product set. While it is tempting 
to quickly select the one “best” product, it is worth remembering that 
it is highly unlikely that a single vendor is the obvious choice for all 
situations. If that were the case, other vendors would have been at- 
tracted to this market niche! 

This book should thus be used as a method of gaining some perspec- 
tive on how computers can be connected together and what they can 
do once they are connected together. By understanding this view the 
reader can begin to evaluate the many different products and features 
and see how they fit into this framework. Its important to remember, 
however, that this is one view of the world, and there are many other 
valid views. 
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DNA Lower-Layer Protocols 


Overview of Lower-Layer Protocols 


The lowest layer of a network, the physical layer, is concerned with 
transmitting a bit of information from one node to another. The fact 
that this bit may continue on over another wire at a later point does 
not yet concern us. Nor does the question of the use of the bit concern 
us: the fact that this bit may be used for a user’s terminal session and 
another bit is part of a file transfer is not yet of importance. 

The wire connecting the two nodes is known as the physical 
medium. The role of the physical layer is to take a stream of bits on 
one node and send them to the node at the other end of the wire. 

The actual type of wire that is used depends on the use that will be 
made of the physical layer. An RS-232-C cable might be an ap- 
propriate physical link for a terminal to a computer. In this case, both 
the terminal and the computer are considered to be nodes and the 
RS-232-C serial cable is the physical link. This is known as a point- 
to-point link because there is one node at each end of the wire. 

Another type of physical media is a coax cable. While an RS-232-C 
cable is limited to a transmission rate of 19,000 bps, a piece of coax 
can easily accommodate rates of 10 mbps. The coax cable can also be 
500 meters (m) long instead of the 76 m limit of the RS-232 cable 
because of the electrical and insulating characteristics of the medium. 

Another distinguishing factor of the coax is that many nodes can be 
simultaneously connected to the same wire. As many as 100 nodes 
can be connected to a single piece of coax. 
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Needless to say, the increased performance and flexibility of the 
coax is offset by the increased cost of not only the cable but of the 
devices used to connect the cable to a node. While a simple $20 con- 
troller port can handle an RS-232-C physical connection, it usually 
takes a separate computer to monitor a piece of coax. 

Physical links are not necessarily a single piece of wire. Two 
modems communicating over a phone line are considered to be a 
physical link. This is because the goal of transmitting a stream of bits 
from one node to another is still met. Other types of physical links 
include very high bandwidth microwave and satellite links. 

Moving a bit from one end of a physical link to the other end is in 
itself not very interesting. For one thing, there is no way of labeling 
each bit to signify what it is for. For this reason there is added a data 
link layer to use a physical link and manage its resources. This 
provides a more efficient use of the physical link by moving blocks of 
bits. 

A typical data link layer takes data and groups it into separate 
frames of information. A frame is a message, complete with an ad- 
dress and contents (the data to be transmited). A frame might be as 
large as 1500 bytes or as small as 1 byte. By grouping data into 
frames, the data link layer is able to append an integrity check to the 
data being transmitted. The data link layer at the receiving end is 
able to use the integrity check to examine the data and make sure 
that it was correctly received. 

A parity check is a very simple example of this type of integrity 
check imposed by a data link layer. On most RS-232-C connections, 
characters are represented by 7 bits of information. Different bit pat- 
terns represent different bits. A parity check adds an eighth bit to the 
data and sends all 8 bits to the remote node. 

When the remote node receives the data, it separates it into the 7 
bits and the parity check. An example of a simple parity check is to 
flip the value of the parity bit for every 1 bit contained in the original 
data. If a character was represented by the bit pattern 1000000, the 
parity bit would be flipped once and would be a 1. The transmitted 
data would be 10000001. If the bit pattern was 1100000, the parity 
bit would flip twice to 0, so the transmitted data would be 11000000. 

More sophisticated integrity checks can also be added by the data 
link layer to detect any errors induced during transmission. Some- 
times the data link layer precedes the data with a length indicator. 
The receiving end then knows how much data to expect. At the end of 
the data may be a more sophisticated integrity check such as a frame 
check sequence. 

Once a packet of data has been successfully sent over a data link, it 
is passed up to a routing layer module. This module is responsible for 
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determining where the packet is destined. Two people communicating 
over a network may have to go through several data links to reach 
their destination. For example, a piece of data may be sent over an 
Ethernet to a VAX, which forwards it over a 56 kbps leased line to 
another VAX, which in turn sends it over another Ethernet to its 
eventual destination. 

The physical layer is not considered in detail in this chapter. 
Specific physical layer support is more properly dealt with in Part 3 of 
this book on network implementation. 


DDCMP Data Link Protocols 


DDCMP is an example of a data link protocol that manages the use of 
an underlying physical medium. The data link layer thus provides a 
point to point link between two nodes on the network. The question of 
taking a piece of information and sending over a series of different 
data links is the responsibility of the user of the data link service, in | 
this case the DNA Phase IV routing protocol. 

DDCMP is a fairly versatile set of protocols and is able to send data 
out over either asynchronous or synchronous links. An asynchronous 
link can be considered to be a mini-synchronous link—each packet of 
data consists of a single byte of data. Asynchronous have more over- 
head because timing and signalling needs to be adjusted for each byte 
instead of for a frame. 

DDCMP is also able to operate over either serial or parallel lines. A 
parallel line sends individual bits down different wires, whereas a 
serial line sends the bits serially down a single wire. 

There are three major components to a DDCMP module: 


a» Framing is the process of taking data and preparing it for transmis- 
sion. 

a Link management manages half duplex or multipoint links. 

» Message exchange is the actual transfer of data. 


The framing component of a DDCMP module monitors the media 
and locates the beginning and end of a message. This occurs at three 
levels. First, the module must locate each bit on the network. This is 
known as bit synchronization. Next, the process of byte synchroniza- 
tion groups data into 8-bit quantities. The final level is message 
synchronization, which groups bytes into frames. 

Byte synchronization is done through the use of a special 8-bit pat- 
tern called the synchronization byte. After that has been received, the 
DDCMP module begins counting bits. Every 8 bits is considered a 
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byte. Needless to say, eventually the framing component can get out 
of sequence. Usually, a sync byte is sent for each message. On an 
asynchronous link, there is no need for a synchronization byte since 
the start-stop nature of the link provides this function. 

The last level of synchronization is message synchronization. Once 
byte synchronization is achieved, the DDCMP module searches for one 
of three message start bytes. Message types can be: 


» numbered data messages 
ws control messages 
= maintenance messages 


The normal type of message is a numbered data message that car- 
ries user data over the link. The first piece of data following the start 
of header (SOH), or message start byte, is a count field that tells how 
long the message is. Because the data is counted, any bit pattern can 
be included in the user data. If the user data happens to have piece of 
data equivalent to a start of message or byte synchronization pattern 
in it, this will not effect the transmission of the data. Only after the 
specified number of bytes has been received does the DDCMP module 
begin looking for unique patterns such as the sync byte. 

Also in the frame header are a series of link control flags. These 
tell the receiving end whether another message will abut this one or, 
failing that, that the receiving end should resync after this message. 
The link control flags also control which nodes on a multipoint link 
control are involved in this particular packet transmission. 

The frame header for a numbered data message also contains a se- 
quence number. The receiving end must acknowledge the receipt of 
each packet by number. This can be somewhat inefficient if each 
packet must be acknowledged, so there are two techniques allowed to 
prevent the acknowledgment of each and every packet. 

Pipelining means that several packets may be sent. When an ac- 
knowledgment is received, the acknowledgment signifies receipt of 
that packet and all lower numbered packets. Thus, an ACK3 signifies 
receipt of packets one, two, and three. 

The second technique for increasing efficiency is to piggyback the 
acknowledgment on a user data packet. One of the fields in the num- 
bered data message header is for a response number. If that field is 
present, it signifies an acknowledgment for that message number. Of 
course, if no user data is to be sent, the acknowledgment cannot pig- 
gyback and must travel in its own separate packet. Figure 2-1 il- 
lustrates'a piggybacked ACK. 

Another type of message used in DDCMP is the control message. 
This is an unnumbered message used to transmit channel control in- 
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Fig. 2-1 Piggybacked acknowledgment in DDCMP. 


formation in a multipoint link. It is also used to transmit status in- 
formation and for initialization of a new link between two protocol 
modules. 

An acknowledgment message is also a form of a DDCMP control 
message. It is used when no user data is going in that direction and 
an ACK is required. A negative acknowledgment has the same format 
but also includes a reason indicator. A negative acknowledgment can 
be generated because the transmission media has corrupted the data, 
either the header or the user data. Another reason for a NAK is 
problems with the computer interface, such as all buffers being cur- 
rently in use. 

The last message type is the maintenance message. This is only 
used in offline mode to test a link. It is similar to the data message 
but does not include any retransmit, error recovery, or other 
mechanisms. 
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Link management 


Link management is the second component of a DDCMP module. It is 
only necessary where the flow of data must be controlled, as in the 
case of either a multipoint or a half-duplex line. A full-duplex line 
does not need this function. 

A half-duplex line is under the control of the data sender. The 
receiver may not send data until it has received permission. On a 
half-duplex line, the sending node sends a selection flag when it has 
completed sending data. This instructs the receiving end to enter the 
transmit mode. 

In a full-duplex environment, either node may send at any time. A 
full-duplex environment requires more resources because each node 
must monitor an incoming and outgoing signal simultaneously. Full- 
duplex environments thus require more buffer space but offer higher 
performance. 

Multipoint links are a special case in DDCMP. One station, the 
control station, is the master of the line. A selection flag is used to 
assign temporary control of the line to a tributary that has data to 
send. The control station polls the tributaries periodically to deter- 
mine if one desires temporary control of the line. 


Message exchange 


The third component of a DDCMP module is the message exchange 
component. Once data has been framed, it is handed off to the mes- 
sage exchange component. This is where acknowledgment numbers 
are actually inserted into the frame header. 

Each message sent by the message exchange component has a mes- 
sage number. Each message must have a positive acknowledgment, or 
ACK. If a negative acknowledgment is received, the message is 
resent. Each message also has a timer associated with it. If the timer 
expires, this is accepted as a negative acknowledgment of the message. 

Time-out values must be set in a way that take into account the 
number of messages that are pipelined, propagation delay, and 
processing delays at the recipient nodes. It is important that a time- 
out value is not short so that a NAK is implied even though the mes- 
sage was correctly received. Typically, transmission of a packet might 
take a few milliseconds. A time-out value is usually a few seconds. 

When a timer expires, it is possible the ACK was lost in transmis- 
sion and the data actually arrived. Rather than resend the entire 
data packet, a Reply to Message Number (REP) packet is sent. This 
has two effects. First, it requires an acknowledgment of the REP mes- 
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sage, which implies an ACK for the original data message. Second, it 
forces the timer to be reset and the two nodes to synchronize their 
message numbering. 

If a timer expires several times, it is logical to assume that the link 
is down. After a user-set number of timer failures, the DDCMP 
module notifies the user of the line failure. Typically, the user of the 
DDCMP service is a DNA routing module. 

One of the DDCMP issues is the amount of processing done at the 
operating system level and the amount that can be built into a 
hardware controller. In the case of asynchronous DDCMP, all process- 
ing is done in the DDCMP module. The data is then sent to the 
asynchronous device driver. Another user of that asynchronous device 
driver might be a terminal services manager. On a VMS node, a par- 
ticular hardware port may dynamically change from terminal mode 
into asynchronous DECnet mode. 

Multipoint links are. supported in DDCMP. Another way to have 
multiple nodes share the same physical medium is the Ethernet data 
link protocol. Because DDCMP uses a polling mechanism, it is not 
optimal for large numbers of nodes sharing the same physical 
medium, when each needs a short response time. In these cases, 
Ethernet is a more suitable data link. | 

DDCMP, unlike Ethernet, does not support any kind of broadcast or 
multicasting facility. On multipoint lines, there may only be one con- 
trol station. That control station must remain fixed and cannot float 
among the multiple tributaries. 


Ethernet Data Link Protocols 


DDCMP as a data link protocol has two significant drawbacks. First, 
it is relatively slow. As will be seen in the wide area network chapter, 
DDCMP links are usually 19 to 56 thousand bits per second (kbps). 
Occasionally, Tl speeds of 1.544 megabits per second (mbps) may be 
obtained. 

The second disadvantage of DDCMP is that it is essentially a point- 
to-point data link mechanism. This works fine in a wide area network 
(WAN) scenario but is not a very efficient way to allow hundreds of 
workstations to communicate with each other. DDCMP is thus used 
to provide point to point links over long distances. Another protocol is 
needed to support the high-speed networking capabilities of a local 
area network. 

Ethernet provides an alternative data link mechanism to connect 
nodes together. Two nodes may be able to communicate over both a 
DDCMP connection and an Ethernet connection. Which of the two 
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alternatives to use for sending a particular data message is the 
responsibility of the routing layer of DNA. As with DDCMP, all we 
are concerned with is how to get some data from one node to another. 
The eventual destination or eventual use of that data does not yet 
interest us. 

Ethernet connects many nodes at a speed of 10 mbps. Up to 1024 
nodes may be part of a single Ethernet. Ethernet looks to the user of 
this data link service like 1024 separate wires with 1024 nodes con- 
nected to them. 

Conceptually, Ethernet looks like a single logical wire, known as a 
bus. In reality, the physical configuration may consist of many dif- 
ferent segments connected together using a set of configuration rules. 
The different physical configuration options are the subject of the local 
area network implementation chapter. 

Ethernet is one of several different techniques for connecting large 
numbers of nodes. It happens to be the principal method advocated by 
DEC. Other alternatives to Ethernet, such as the token ring or the 
token bus, will be discussed in subsequent chapters. 

Because Ethernet is incorporated into the DNA, this is a convenient 
place to introduce it. Later chapters contain more information on 
Ethernet in other architectures and on the physical configuration of an 
Ethernet network. DNA happens to use Ethernet as a way of making 
two DECnet nodes communicate with each other. In this case, the 
user of the Ethernet service is the DNA routing layer. 

Other users of the Ethernet include other networking architectures 
(See Figure 2-2). Two DEC networking architectures, for example, are 
able to use the services of the Ethernet. The Local Area Transport 
Architecture is a set of protocols that allow terminals to use an Ether- 
net to efficiently communicate with a host. As will be seen, both DNA 
traffic (host to host) and LAT traffic (terminal to host) can share the 
services of the Ethernet, just as different kinds of businesses can all 
share the services of the phone network. 

Another DEC-developed user of the Ethernet service is the System 
Communication Architecture that is used for VAX Clusters. While 
DNA is a very general purpose architecture for many nodes, the SCA 
is a special purpose architecture that allows just a few nodes to par- 
ticipate in a closely coupled environment. 

It is not unusual to see a single VAX computer speaking three dif- 
ferent languages. The first language is DNA, which is used to trans- 
mit electronic mail, remote file transfers, and remote log-in to 
anywhere on the network. ‘The VAX computer thus has a set of 
software for speaking DNA, which ultimately requires the service of 
Ethernet, DDCMP, or other data link layers to transfer data to 
another node. 
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Fig. 2-2 Multiple Ethernet clients. 


The second language that the VAX speaks is LAT, which is used to 
communicate with terminals connected to a special-purpose computer 
called a terminal server. This LAT software also requires the services 
of the Ethernet. As you can see, the Ethernet is a general-purpose 
service provider. 

The third client might be the System Communication Architecture 
(SCA), otherwise known as a VAX Cluster. The cluster allows many 
different computers to share a single disk drive. Since the disk drive 
is an expensive peripheral, VAX Clusters allow a single high-perfor- 
mance disk drive to be shared among many users. Other clients of the 
Ethernet may include non-DEC architectures such as TCP/IP or XNS. 
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There are thus four different architectures that will use the services 
of the Ethernet: TCP/IP, LAT, SCA, and DNA. Three other chapters 
discuss increasing levels of complexity of Ethernet implementation. 
The local area network chapter discusses how to configure a basic 
Ethernet, consisting of multiple segments and repeaters. The wide 
area network chapter will discuss how to extend these Ethernet sys- 
tems over wide areas. Finally, the chapter on OSI lower layer 
protocols provides a more general abstract model of how Ethernet 
works with other types of media to provide internetworking 
capabilities. 


CSMA/CD media access control 


Several different methods allow many nodes to share one logical piece 
of cable. Ethernet is based on a technique called Carrier Sense Multi- 
ple Access/Collision Detect (CSMA/CD). This is known as a Media Ac- 
cess Control or MAC Protocol because it controls how different nodes 
gain access to the media. Other MAC protocols are token rings and 
token buses. 

The “Multiple Access” part of CSMA/CD means that every node con- 
nected to the Ethernet is able to access the media. There is no master 
node which polls and gives permission to speak, as we saw in the case 
of DDCMP multipoint links. Every node can access the media at any 
time. 

“Carrier Sense” means that the nodes have the ability to sense if 
another node is currently transmitting data. If another node is cur- 
rently transmitting, the Ethernet node knows enough to refrain from 
sending at the same time. A node can only send 1500 bytes of data at 
one time, so a single node is unable to monopolize the media. 

The fact that each node can send packets out means that occasional- 
ly two nodes will transmit at the same time. This happens when both 
nodes monitor the network and start sending at exactly the same 
time. This is known as a collision. The collision is identical to two 
people talking at the same time—they may feel better, but they have 
exchanged no information. 

A collision results in what can be described as a situation of some- 
what controlled anarchy. Each node involved in the collision stops 
sending and then waits for a random period of time. Needless to say, 
that random period of time is different for each node. At the end of 
this time, the node then listens again to the media to see if it is avail- 
able. 
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Ethernet Version 2.0 


Ethernet was originally developed by DEC, Intel, and Xerox. This 
original specification is currently in its second revision. Subsequent to 
the original Ethernet work by the three developers, the question of 
LANs was considered by the IEEE. The IEEE generalized this model 
to provide support for a more general LAN architecture. 

Each Ethernet station has a physical address that is assigned when 
the device is shipped from the manufacturer. Xerox administers ad- 
dresses to ensure that each device is unique. Each device monitors 
the Ethernet and listens for any frames that are addressed to it. It is 
possible for the network administrator to replace the globally ad- 
ministered address shipped with the hardware with a local address 
determined locally. 

In addition to the specific physical address, a station monitors the 
Ethernet for two other kinds of addresses. A broadcast address is 
automatically picked up by every station on the Ethernet. A multicast 
address is picked up by a subset of stations on the network. 

Different users of the Ethernet will all make use of multicast ad- 
dress. Later in this book we will examine several DEC-defined multi- 
casts, including ones for a DNA Load Assistance in the MOP protocols, 
routing layer control messages, LAT service broadcasts, and System 
Communications Architecture broadcasts for nodes attempting to join 
a Local Area VAX Cluster. 

The interface that different users of the Ethernet use is called a 
portal. The portal database contains a list of protocol types and multi- 
cast addresses that are destined for that particular user of the Ether- 
net. Each node on the Ethernet monitors the medium for all packets 
containing the broadcast address or any of the local and multicast ad- 
dresses that are registered in the portal database. The Ethernet takes 
each of these packets received, strips off any header information, and 
then passes the data up to the service user. 


IEEE 802.3 LANs 


The original Intel/DEC/Xerox specification for the Ethernet was taken 
over by the IEEE standards committees and extended. DECnet sup- 
ports both versions of Ethernets. While there are a few minor electri- 
cal differences between the two specifications, the differences are neg- 
ligible for all but the makers of transceivers. 

The major extension provided by the IEEE committees has been to 
generalize the standard to support a variety of different local area 
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network technologies. This was done by splitting the data link layer 
into sublayers. 

The original Ethernet CSMA/CD access techniques are part of the 
lower sublayer, called the media access control. In addition to 
CSMA/CD LANs, the IEEE specifications support other MAC layers 
such as the token ring or token bus access methods. 

The upper sublayer is called the logical link control (LLC). This 
sublayer provides a single interface to the users of the local area net- 
work. This allows a single routing layer to utilize different kinds of 
LAN technologies. Thus, the IEEE protocols allow several users to 
use a single data link layer mechanism. Each of the users sends pack- 
ets of information to the LLC sublayer. Underneath the LLC sublayer 
a variety of different MAC sublayers can reside. The LLC sublayer 
functions as a simplifying mechanism that allows multiple users to 
use multiple LAN technologies using a common packet format. 

There is a slight difference in the packet formats between an IEEE 
CSMA/CD MAC layer and the original Ethernet packet. In Ethernet, 
a type indicator follows the source and destination addresses. The 
type indicator has been moved out of the MAC layer in the IEEE for- 
mat and a length indicator immediately follows the source and des- 
tination address. 

The two formats have been made compatible using a simple trick. 
The length of a packet in both instances is between 46 and 1500 bytes 
long. To avoid a conflict, type indicators do not fall within this range. 
By examining the third field of an incoming packet, the Ethernet con- 
troller board is able to immediately distinguish between the two types 
of formats. 

The type indicators in the original Ethernet have been replaced with 
a logical link control header which is embedded inside of the MAC 
packet header and contains a source and destination address. This 
format allows more flexibility for further expansion than the single 
type field in the original specification. 

There are three classes of logical link controls. Present LAN im- 
plementations use LLC class 1, which is simply a datagram service. 
This means that the LLC service consists of accepting a single packet 
of data and sending it out over the network. No error recovery or 
virtual connections are provided. 

The LLC standards include two further classes that will be used to 
provide increased functionality at the LAN layer. LLC class 2 
provides a connection-oriented service at this layer of the network. In 
DNA Phase IV, it is the responsibility of a higher layer of the network 
to provide this functionality. Embedding a connection-oriented service 
into lower layers of the network has the advantage of allowing much 
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of the connection-oriented functionality to be provided in dedicated 
hardware controllers instead of in the main memory of the system. 
The third LLC class provides a connectionless service like the first 
LLC class. However, LLC class 3 provides an acknowledgment for the 
receipt of the packet. In LLC class 1 operations, if a packet does not 
reach its destination, it will be the responsibility of a higher layer of 
the network to discover the error and provide some form of recovery. 


Routing 


The data link layer provides an ability to connect two nodes on the 
same wire. In the case of Ethernet, there are actually many nodes 
sharing the same wire. However, the Ethernet module masks this 
multiaccess nature of the media and provides a virtual point-to-point 
link. Likewise, multipoint DDCMP links also look like a series of vir- 
tual point-to-point links because the DDCMP module masks the 
process of polling and granting access to selected nodes. 

The routing layer is responsible for taking a packet from data link 
and deciding which data link to send the packet back out on. The 
routing layer thus takes a series of data links and forwards a packet 
from the source to the destination. In this case, the destination could 
be separated from the source by many hops (individual instances of a 
datalink). 

The routing layer thus masks the topology of the network from the 
users of the routing service. Higher layers of the network are able to 
assume that they can talk directly to their destination. At this point, 
we are still not concerned with what the data is going to be used for or 
who the user of the data is. This functionality will provided by yet 
another module. 

A byte of data destined for data transmission has now been twice 
packetized. First, the routing layer receives data and puts a routing 
layer header on it. All of this information is then considered to be 
“user data” for the data link layer. The data link layer puts its own 
packet header on the information. 

Figure 2-3 shows some data being transmitted on an Ethernet with 
both Ethernet (data link) and routing headers on it. Normally, the 
data on the Ethernet consists of a series of bits. A tool called a net- 
work analyzer is used to observe Ethernet packets and translate the 
control information into high level indicators. 

This book makes extensive use of screen dumps of this sort to il- 
lustrate various networking protocols. The particular product used is 
the Sniffer, made by Network General. This network analyzer con- 
sists of a special purpose portable computer, usually either a Compaq 
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Fig. 2-3 An Ethernet packet delivering routing info. 


or a Toshiba 3200. The Sniffer also has special-purpose software for 
analyzing and managing data as well as network adapters. While 
these examples use an Ethernet controller to observe Ethernet, the 
same basic hardware can also observe other LAN technologies such as 
token rings. 

Data links between individual nodes on a network are subject to 
failure, as are individual systems in the network. Because this is a 
fairly common occurrence, the routing layer has to be able to adapt to 
changes in the network topology. If one line goes down in the net- 
work, the routing layer is able to take an individual packet and send it 
over an alternative route. Only if no routes are available is the user 
of the routing service notified of a network error. Otherwise, the 
dynamic topology of the network is transparent to the upper layers. 

An important concept in DNA Phase IV routing is that the routing 
layer provides adaptive routing only for topographical failures. A par- 
ticular path is designated as the best path to a particular end destina- 
tion. Only if that line goes down is an alternative route found. 

To illustrate this concept of adaptive routing for topographical chan- 
ges, imagine that there are two lines to a particular node. A 56 kbps 
line is considered to be the best path. There is also an alternate path 
consisting of a 9600 bps line. Even if the 56 kbps line is nearing 
saturation, all traffic is pumped down that path and the 9600 bps line 
remains idle with respect to this particular source and destination 
combination. 
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As will be seen, path splitting is a special exception to this rule. If 
there are two lines that have equal costs, as determined by the rout- 
ing decision algorithm, packets will be distributed between the two 
lines in a round-robin fashion. Note that this still does not account for 
actual traffic on the two lines—it is not adaptive routing based on 
actual loads on the system. 

The routing module has four major functions. The primary function, 
of course, is routing. The initialization function sets up a data link 
layer and connects to adjacent nodes. Congestion control is a function 
that prevents a node from flooding the network with packets. Packet 
lifetime control, the last function, destroys packets that have already 
visited too many nodes. 

There are several things that the routing layer does not accomplish. 
The DNA routing layer does not provide for different classes of traffic. 
The next layer up, the end communication layer, has some limited 
capabilities to prioritize traffic through the use of other-data logical 
links. The routing layer itself does not have any capability to distin- 
guish among different priorities of delivery. 

The routing layer also does not react to the amount of traffic on a 
line. It does dynamic routing, but only for topographical failure. Once 
a particular routing path has been determined to be the least-cost 
path, it is used for all packets regardless of congestion. If multiple 
paths of equal cost exist, the routing layer is able to distribute packets 
among the different routes in a round-robin fashion. 


Types of nodes in a network 


A DECnet has two types of nodes. A routing node, typically a VMS 
system or a dedicated router consisting of special hardware and 
software, is able to provide routing services to other nodes on the net- 
work for route-through traffic. 

An end node is a full member of the DECnet and can send and 
receive traffic. An end node, however, is unable to provide routing 
services for other members of the DECnet. Implementations of 
DECnet under Ultrix and on MS-DOS are examples of end nodes. 
Third party clones of DECnet, such as those that run on the Apple 
Macintosh, are also end node implementations. Needless to say, it is 
significantly easier to implement an end node version of DECnet than 
it is to implement a full routing version. 
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Fig. 2-4 DNA routing layer cost calculation. 
Routing Decisions 


The actual routing decision is the most complicated component of the 
routing layer. There are four separate processes involved in the rout- 
ing component: 


a the decision process, 

a topology updates, 

a forwarding of packets, and 
ws receiving packets. 


The decision on which path to pick in a network is a function of the 
cost of different routing paths. Each link between two nodes is con- 
sidered to be one hop. Every node on an Ethernet is one node away 
from every other node on the Ethernet. Every hop on the network is 
assigned a cost. Figure 2-4 illustrates a routing topology with a least- 
cost path calculation. 

Each time a packet is received from an adjacent node, the receiving 
node must decide how to forward the packet. Based on the least cost 
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path, the node is able to decide which adjacent node should next 
receive the packet. Note that each node along the delivery path 
reexecutes the decision process. 

Costs are assigned by the network manager. These numbers are 
arbitrary. Usually, the cost figures have some relationship to the 
bandwidth of the media. A 56 kbps link would have a lower cost than 
a 9.6 kbps link. Another factor used in assigning costs is the number 
of nodes sharing a broadcast circuit. If 1000 nodes share an Ethernet 
that circuit should have a higher cost than another Ethernet that has 
only 3 nodes on it. 

A routing node continually monitors the circuits that are directly 
attached to it. If the node detects a circuit failure, it must notify other 
routing nodes on the network of that failure so they may update their 
routing databases. 

Notification of other nodes is done through a routing control mes- 
sage. This message contains path cost and path length for all destina- 
tions. A level 1 router would send a routing control message to all 
adjacent routing nodes within its home area. A level 2 router would 
send a routing control message to all adjacent level 2 routers. The 
concept of different levels of routing is discussed in the next section. 

To stop routing control messages from flooding the network there is 
a parameter called the rate control frequency timer, which sets the 
minimum time period before another routing message can be sent. 
This timer is usually set at 1 second. 

Routing control messages on an Ethernet are sent via a multicast 
address. All routers on the Ethernet enable receipt of this multicast 
address as part of the data link initialization process. It is important 
that there are not an excessive number of routers on an Ethernet, if 
there are, they will flood the network with routing control messages. 

An Ethernet has special routing algorithms because of the broadcast 
nature of the media. There may be several routers on an Ethernet. 
Each of these nodes sends routing control messages to each other. 
When a new router joins the Ethernet, it sends a NEWROUTER mes- 
sage out. If the number of routers has not exceeded the predeter- 
mined number, each routing node updates their tables. 

On the Ethernet, one node is known as the designated router. This 
node periodically sends messages to all end nodes on the network in- 
forming them of its address. End nodes each have a limited cache, 
containing the destination of other nodes that are on the Ethernet. If 
the end node attempts to communicate with another node not in the 
cache or not on the Ethernet, it sends the packet to the designated 
router. Figure 2-5 illustrates a HELLO packet from a new router on 
the Ethernet. 
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Fig. 2-5 A router HELLO message on Ethernet. 


Areas 


The process of continually updating dynamic routing tables becomes 
increasingly difficult as the number of nodes increases. In order to 
maintain the efficiency of the routing module, DECnet limits this 
process to groups of 1024 nodes. For large customers, this provides a 
severe limitation to their ability to provide one common network. In- 
cluded in this group of large customers is DEC, which has an internal 
network of well over 30,000 nodes. 
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To provide large networks, DECnet segments nodes into areas. A 
single area has up to 1024 nodes and provides the full adaptive rout- 
ing algorithms. In addition, up to 63 areas can be connected together 
to form a multiarea DECnet. 

Routers that provide functionality within an area are known as level 
1 routers. Routing between areas is provided by level 2 routers. The 
level 2 routing scheme consists of a series of static links between dif- 
ferent areas. Figure 2-6 illustrates a DNA topology that has two 
areas. 

Level 1 routers are not required to know about different areas in the 
network. When they receive a packet destined for another area, they 
forward that packet to the nearest level 2 router. The level II router 
then forwards the packet to its peer level 2 router in the destination 
area. That level 2 router hands it off to a level 1 router which delivers 
it to its eventual destination. 

Levels 1 and 2 thus provide a hierarchical routing scheme. One set 
of routing decisions is made for level 2 routing and then a further 
series of decisions are made by the level 1 routers. Level 2 routing 
allows the establishment of very large networks. 

Even a network of 63,000 nodes has proved to be a limitation. DEC, 
for example, has pushed the limits of Phase IV networks because of 
the large growth of the internal EasyNet system. For this reason, 
among others, DECnet Phase IV is being supplanted by Phase V. 
Phase V has an address space of 20 bytes instead of the 20 bit Phase 
IV address space. This allows networks consisting of up to 10*® nodes, 
enough to hold even DEC for a few years. DECnet Phase V is con- 
sidered in more detail in Part 4 of this book in the chapters on Open 
Systems Interconnect. 


Congestion and lifetime control 


Congestion control is an important part of the routing process. If the 
network is already congested, it is important not to send more packets 
out onto the already scarce bandwidth. The routing layer will ar- 
bitrarily destroy packets under certain types of congestion. It is up to 
the end-to-end communications layer to detect that a packet was not 
received and to resend it. 

At first glance, it seems wasteful to have a routing layer throw out a 
packet rather than buffer it for future transmission. The reasoning 
behind this design decision is that a congestion problem is a transient 
phenomenon. Usually there is either a node or circuit failure or there 
is a temporary high load on a particular route. If the load is high, one 


44 DEC Networks and Architectures 


LEVEL 1 
ROUTING 


LEVEL 2 
ROUTING 


Fig. 2-6 Inter-area routing in DNA. 


can expect that situation to change shortly. If the load remains exces- 
sively high, the network manager needs to reconfigure the network. 

If there is a node or circuit failure, there will shortly be a routing 
control message sent which will be transmitted throughout the area or 
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among areas. In either case, by the time the source end communica- 
tion layer has noticed the lack of acknowledgment of a particular seg- 
ment, routing control messages will have propagated throughout the 
network and the packet will be sent via an alternative route. 

There are several kinds of congestion control used in a DNA net- 
work. First, there is a limit on the number of packets that can be 
queued at any one time for transmission. This queue limit is a func- 
tion of the number of routing layer buffers available and the number 
of active output circuits. All packets, whether local or route-through, 
above this are discarded. 

A second kind of congestion control is the originating packet limiter. 
The routing module is able to distinguish between local and route- 
through packets. The originating packet limiter ensures that a certain 
percentage of routing resources is always available for route-through 
traffic. This means that under certain conditions, route-through pack- 
ets are accepted while local packets are rejected. This is because the 
network already has a substantial investment in the route-through 
packet. Again, it is assumed that this condition is a transient one and 
that resources will become available shortly and the local packet will 
then be transmitted. 

A third kind of congestion control is a flusher. Any packets in- 
tended for an adjacent node that has failed are flushed. It will be the 
responsibility of the sending end communications layer to resend those 
packets after a time-out period. The queue of packets intended for the 
failed node (or failed circuit) could have originated from a wide variety 
of nodes in the network. Rather than require the local routing layer 
to notify each of these different nodes that a particular packet was not 
sent, a single routing control message is sent network wide. 


Summary 


The first three layers allow a node on the network to send a packet of 
information to any other node on the DECnet. The data link and 
physical layers together are concerned with delivering information be- 
tween a pair of nodes. Using multiple access media, such as the 
Ethernet, many nodes can actually be connected to a single piece of 
physical wire. The data link layer, however, makes this look like a 
series of virtual wires between each of the nodes connected to the 
Ethernet. 

The routing layer takes these series of point-to-point links, whether 
real or virtual, and combines them into a large network. The function 
of the routing layer is thus to decide which combinations of individual 
data links form a path to a particular destination. This path may 
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consist of combinations of satellite links, microwave, dedicated 
telephone lines, or Ethernets. Users of the network layer are unaware 
of this network topology and can thus focus exclusively on the tasks 
they wish to accomplish, such as file transfer, without worrying about 
the underlying topology of the network. 

We will see that several sophisticated services are built on top of 
this underlying network service. The first user of the network will be 
the transport layer of the network. The transport layer takes an un- 
derlying network connection and allows many users, such as file 
transfer users or virtual terminal service users, to share the network 
service. The transport layer thus provides a way of using one network 
for multiple users. Upper layers will then allow those individual users 
to perform their tasks. 
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DNA Upper-Layer Protocols 


Overview of Upper Layer Protocols 


The network services, or lower layers, of DNA provide a service of 
delivering data from one node on the network to another node. The 
upper-layer services take this data and deliver it to particular users of 
the network. 

The bridge between the network services and the upper-layer ser- 
vices, such as data access, is provided by the transport and session 
layers. In DNA Phase IV, the transport layer is known as the end-to- 
end communications layer and uses a set of protocols called the Net- 
work Services Protocol (NSP). The function of NSP is to form a series 
of logical links between users. NSP thus serves as a form of multi- 
plexer which takes many different users and delivers a single stream 
of data to the network services. Each packet of data is delivered by 
the network services and then demultiplexed at the destination. 

The session layer forms a bridge to the services of DNA. While NSP 
is responsible for delivering data to end user services, it is the respon- 
sibility of the session layer to determine if that end user exists and to 
validate access in the context of the security domain of the operating 
system. The session control layer is also responsible for mapping a 
logical DECnet node name composed of an alphanumeric string into a 
DECnet address consisting of an area and node designation. 

The upper layers of DNA perform a variety of functions. The two 
primary Phase IV services are remote log-in and remote data access. 
The CTERM protocols provide a remote log-in service by taking a 
validated logical link and supplementing it by managing the particular 
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characteristics of a terminal session. The Data Access Protocols are a 
separate set of protocols used to access remote data, including in- 
dividual records in a file and attributes of a file such as the size or 
security attributes. 

A variety of other services are also available in DECnet. For ex- 
ample, two different mail delivery protocols exist. The mail-11 
protocols are used for traditional VMS mail delivery services. A more 
modern set of protocols centered around the mailbus architecture are 
also available. Message handling systems are considered in more 
detail in the OSI upper layers chapter. 

Another service is a videotex service. This allows remote access to 
data in a VTX “info base” located anywhere in the network. Several 
other services have been built on top of the network that are not con- 
sidered in detail in this book. For example, a bulletin board service 
based on the VAXnotes software is available. As will be seen in the 
discussion of the session control functions, it is quite simple to build 
network-based services in DECnet. This is because services such as 
DAP and the session control databases allow the network to function 
as a simple extension of the individual node. 


Network Services Protocol 


The Network Services Protocol of the end-to-end communications layer 
is closely coupled with the session layer protocols. NSP provides a 
logical link service to the session layer. Together, they take data that 
the routing layer has delivered to the proper node and deliver it to the 
proper user on that node. 

The basic NSP concept is a logical link that connects two session 
control modules. The session control modules turn the logical link 
into a session, which is then used between two higher layer services, 
such as a virtual terminal session. Figures 3-1 and 3-2 shows NSP 
traffic on an Ethernet. 

There are four major NSP functions: 


a Establishing and destroying logical links 

s Error control 

s Flow control 

» Segmentation and reassembly of messages 


When a session layer module requests a logical link, it submits a 
CONNECT-XMT message to the NSP module. The NSP module submits 
it to the routing layer, which delivers it to the target NSP module. 
The target NSP module sends the source NSP module an acknow- 
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Fig. 3-2 An NSP packet. 
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ledgment that it has received the request. It then notifies the session 
control module, which can ACCEPT or REJECT the request. When the 
target session control module accepts a session request, it notifies the 
target NSP module, which sends back a connect confirm message. 

Sometimes, a connect request is received on a node that has no 
resources available for new logical links. The NSP module is able to 
reject this request without notifying the session control module of the 
incoming request. 

Within a logical link, there are two data subchannels. The normal 
data subchannel is used for data passed in from higher-level modules. 
The other-data subchannel is used for interrupts and other out-of-band 
signaling. The function of the other-data subchannel is to move an 
interrupt signal to the head of the transport layer queue. Since the 
routing layer has no prioritization capabilities, this does not result in 
the routing layer delivering the data more quickly. However, it does 
bypass any data in the transport layer queues. 

Within each subchannel, messages are numbered sequentially. 
Each message sent must be acknowledged or the sending NSP module 
will retransmit the message. Pipelining allows the receiving NSP to 
acknowledge several messages by acknowledging receipt of the 
highest-numbered message. The receiving NSP module can only wait, 
however, for a period of time that is less than the sending node’s time- 
out factor. 


NSP flow control 


There are several flow control mechanisms that are available within 
the NSP modules. When a logical link is being formed, the NSP 
module at each end tells the other side what type of flow control to use 
when sending it data. Three options are no flow control, segment flow 
control, and session control message flow control. 

Segment flow control is accomplished by sending a request count 
parameter. The sending NSP may only have that number of messages 
outstanding. It looks at the highest-numbered message segment that 
has been acknowledged, adds the request count parameter, and then 
sends messages segments until it reaches that sequence number. 

Session control flow control operates the same way, but instead of 
using individual message segments, the request count parameter 
refers to the entire message. The NSP module thus looks for the 
highest acknowledged end-of-message segment and adds the request 
count parameter to it. 

Since a logical link is full duplex, each side of an NSP logical link 
may request different flow control mechanisms. A large VAX con- 
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nected to a PC might have a session. The VAX, as a data receiver 
with a large buffer space, might request either no flow control or seg- 
ment flow control with a large request count parameter. The PC 
would have very few restraints on the amount of data it can send. On 
the other hand, the PC as a data-receiving NSP module would probab- 
ly request a fairly small request count parameter. 

In addition to the normal flow control, either end of a session may 
also use an On/Off control mechanism. The data-receiving module re- 
quests that no further messages be sent until an ON message is trans- 
mitted. 

The other-data subchannel uses a message-based flow control 
mechanism. When a logical link is established, there is an implicit 
request count parameter of one. This means that an interrupt mes- 
sage must be acknowledged before a second one is sent. 

One of the prime functions of the NSP module is segmentation and 
reassembly of messages received from the session control module. A 
single segment is limited by the size of data that the network services, 
or routing, layer can accept. NSP takes data from a session control 
buffer, breaks it into segments, and submits each individual segment 
to the routing layer. 


NSP components 


An NSP process has three types of components: databases, buffer 
pools, and modules. Figure 3-3 illustrates the structure of an NSP 
process. Note that these are functional components. The division of 
functionality in an architecture helps show what a particular layer is 
supposed to accomplish. Often, several components are combined into 
a single process. Any NSP implementation that can receive a call 
and submit the proper messages to a routing layer is considered a 
valid NSP implementation. 
There are four databases used by NSP: 


a The NSP internal database 
a The reserved port database 
a The session control database 
a The node database 


Thé first two databases are used internally by NSP to manage itself. 
The NSP internal database contains information and parameters used 
in the internal management of the NSP module. An example of a 
parameter would be the maximum number of logical links allowed on 
this node. 
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A port in NSP is equivalent to the Ethernet concept of a portal. 
Both refer to a particular registered user of the service. Normally, the 
user of the end-to-end communications layer is the session control 
layer. The reserved port database contains a list of resources that 
NSP modules use for exchanging control messages that are not 
mapped into any session control port. 

The other two databases can be thought of as interfaces to other 
layers. The session control port database is an interface to the session 
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control layer. When the NSP module sets up a logical link, it allocates 
one of the available ports to the session control layer. When the logi- 
cal link is destroyed, the NSP module frees the port and returns it to 
the database. The node database contains information on each of the 
nodes with which a logical link is established, including traffic usage 
counters and estimates of the round-trip communications delay. 

Buffers are how data is exchanged with other modules in the Digital 
Network Architecture. A receive buffer pool contains data received 
from the routing layer. An event buffer pool is used to queue events 
that are then put into an event queue (another type of buffer) for 
processing by the network management layer. 


NSP modules 


Several types of modules operate within the confines of the larger NSP 
module. The interface routines intercept all calls from session control 
and provide a unified calling environment. If a message is to be trans- 
mitted, it is sent to a segmentation module, which breaks the message 
up into segments of appropriate size. The transmit buffer pool is used 
as a queue to the routing layer. The transmit process polls the rout- 
ing layer to determine when transmission of certain buffers has been 
completed. 

The receive dispatcher module also works with the routing layer. It 
polls the routing layer for received messages and then dispatches 
them to the appropriate receive processes. Each logical link has its 
own processes, which manage the logical link state. The receive 
process sends data up to be reassembled, which in turn is sent up to 
the session control layer. 


Session Control Layer 


When a session control receives a logical link request from an end 
user on the local node, it must first identify the destination address. 
In addition to the required name mapping database, some DECnet 
nodes also contain an alias database which allows users to specify ad- 
ditional names for destination addresses. Figure 3-4 illustrates the 
relation of the session control database to the operating system and 
the lower layers of the network. 

The session control module must then format a connect request that 
will be passed to the destination session control module. This infor- 
mation might contain a user name and password. Other times, the 
connect data will not specify this information, and the module will 
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Fig. 3-4 Session layer functions. 


attempt to use default accounts on the destination node, if that node 
has those enabled. 

The session control module passes the connect request to the net- 
work services layer. If an outgoing timer has been enabled, the timer 
is started. The module waits for a packet with this logical link iden- 
tifier to be received from the network services layer indicating that the 
destination session control module has accepted or rejected the re- 
quest. If the timer was set and no reply was received, a rejection is 
assumed. 

Upon receiving an incoming request, the destination network ser- 
vices module notifies the session control module of the incoming logi- 
cal link address and passes a buffer containing the connect data. The 
session control module parses the connect data and validates the ac- 
cess control information. It then either identifies, creates, or activates 
the destination end user and passes connection information to the end 
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user processes, attempting to parse the source address into a logical 
node name. If the node name is not contained in the mapping 
database, the end user layer is notified that an unknown node is com- 
municating. 

Once a session has been established, the two session control 
modules act as a conduit for data for the upper-layer services. If an 
end user instructs the session control module to disconnect or abort, 
the module passes a 2-byte disconnect code and up to 16 bytes of dis- 
connect data to the network services. 

The session control layer can log two types of events in an event log 
for the network management layer. Changes in node state are logged 
along with any access control failures. Most systems also log success 
log-in attempts in the normal operating system accounting file. Figure 
3-5 illustrates a session control connection request. 


Session control databases 


The session control layer has two databases that are used during net- 
work operation. These are: 


ws A node name mapping table 
ws A session state database 


The node name mapping table translates logical addresses into the 20- 
bit DECnet address. One of the problems in a large Phase IV network 
is updating the session control database on all nodes of the network. 
Even though a node is reachable at the routing layer, users of network 
services need the logical name. It is much easier to ask for FILESER- 
VER::FILE.DAT than it is to remember that FILESERVER has a DECnet 
address of 2.136. 

Phase V of DECnet will expand the session control layer to include 
a distributed naming service. New nodes or services entering the net- 
work can register themselves with the DNS. If an unknown node 
name is received from an end user, the session control layer will be 
able to query DNS as to the validity of that name. 

The second database kept by the session control layer is a state 
database. A particular session control module can be operating in one 
of four different modes. When the module is off, there are no logical 
links operational. In SHUT state, the module keeps existing logical 
links in operation but will not accept new requests from either another 
session control module or from an end user process. RESTRICTED is 
like the SHUT state but does accept new logical links from users with 
sufficient levels of privilege. On is the state for normal operation. 
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Fig. 3-5 A session control packet. 


The state database can also contain default connection timers. 
When an incoming request is received, the session control module pas- 
ses that request to an upper-layer process. Normally, this upper-layer 
process is under no time constraint to accept or reject the request. By 
setting a timer, the network manager allows the session control 
module to assume a request has been rejected upon expiration of the 
timer. 
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DNA objects 


A connect request from an end user process usually contains an object 
type to indicate the type of service required to the destination session 
control module (See Figure 3-6). An object type 4, for example, is for 
the CTERM protocols in the virtual terminal service. An object type 
17 is for the Data Access Protocol. An object type 0 is for non- 
registered object types, which must be further specified by the re- 
questing end user. In VMS, for example, the user would specify the 
destination task as: 


NODE::"task=taskname.com" 


This is equivalent to an object type 0 call for a user-written program 
called TASKNAME.COM. In this case, the destination VMS would look 
either in the requesting user has a proxy log-in or would look in a 
default area for object type 0 execution to see if TASKNAME.COM exists. 

If the end user in VMS had wished to specify an account to run the 
task in, the syntax would have been: 


NODE"username password"::"task=taskname.com" 
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In many networks, there is a default area for FAL access as well as 
for object type 0 execution. If these two default areas are the same, it 
is possible to copy a file to a remote node, then have it executed at the 
remote node, and the results copied back. This provides an easy way 
to either steal or borrow CPU cycles. 


Virtual Terminal Service 


The virtual terminal (VT) service is one of two ways to allow a remote 
terminal to access a host system. The Local Area Transport protocols 
are an alternative service that provides similar functionality. Both 
services allow a host to treat all terminals, remote or local, in the 
same way. The LAT protocols are a non-DECnet set of protocols that 
interface directly with the Ethernet. LAT is more efficient than the 
DECnet virtual terminal service but is limited only to use on Ethernet 
devices. The DECnet VT service, on the other hand, is able to operate 
over any DECnet configuration. 

The virtual terminal service consists of two sublayers. The terminal 
communication module establishes a data stream between two nodes 
on the network. This module can be thought of as an extension of the 
session control layer in that it binds two terminal services managers 
together into a session. 

The command terminal module is the upper sublayer of the virtual 
terminal service. The command terminal protocols provide the actual 
I/O exchange between a host and a terminal. The virtual terminal 
service is usually referred to as CTERM after the command terminal 
module. This is in contrast to LAT-based services. 

To establish a terminal session there are two nodes involved. The 
server is the local node that actually has the terminal connected. The 
host node is the remote node to which the user wishes to connect. The 
terminal communication module allows the host node to treat all ter- 
minals as though they were local. This allows software to function 
effectively across a network, irrespective of the location of the users. 
Figure 3-7 illustrates CTERM traffic on an Ethernet. 

There may be several nodes in between the host and the server in a 
virtual terminal connection. The VT process on the server side con- 
structs messages. These messages are sent down to the network ser- 
vices layers. These layers may route the message through many dif- 
ferent nodes. Eventually, the message is received by the network ser- 
vices layer at the host node which sends it up to the host virtual ter- 
minal modules. This is in contrast to the LAT protocols, which only 
work with nodes that are one hop away from each other on the Ether- 
net. 
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Fig. 3-7 CTERM traffic on an Ethernet. 


The terminal communication module first begins by binding two ses- 
sions together. It then notifies the remote module to enter a par- 
ticular mode. The only mode currently defined is the CTERM module. 
Users could define their own modes, to be used on other kinds of ter- 
minals such as non-VT100-type terminals. Finally, the terminal com- 
munication module dispatches a series of data messages. These mes- 
sages contain CTERM commands. Figure 3-8 illustrates some 
CTERM commands and their function. 

The CTERM module is used to. carry out the actual terminal func- 
tions. The CTERM modules recognize standard VT-style escape se- 
quences, which are a superset of the ANSI standard. CTERM 
modules can read and set terminal device characteristics. Like local 
terminals, the CTERM module is able to read and write to a device 
concurrently. This includes support for a type-ahead buffer, so the 
user may type in characters even though the program on the host has 
not yet issued a read request. 


Data Access Protocols 
DAP is a language used to access data across the network. It uses a 


session established at the lower layers of DNA and then provides addi- 
tional functionality for the specific purpose of data access (as opposed 
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Command Terminal Protocol Messages 


Message Type Function 

Initiate Verify protocol version num- 
bers and other initialization in- 
formation. 

Read Issues a read request to the 


server terminal manager. Car- 
ries the data to the host sys- 
tem. Can also send unread 
messages to cancel requests (in 
response to an interrupt re- 
quest) 


Out-of-band Carries out-of-band data such 
as interrupt requests. 


Write Writes data to terminal and 
receives a confirmation that 
the write completed successful- 


ly. 


Characteristics | Reads and sets terminal charac- 
teristics. For example, can 
dynamically change terminal 
type from ANSI to VT100. 


Buffers Can check status of input and 
type-ahead buffers. 


Fig. 3-8 CTERM messages. 


to remote log-in, Videotex, or other network services). DAP allows 
users to get files from remote input and store them on a remote out- 
put device. Multiple data streams can share a common data link, al- 
lowing for the use of wild cards and other similar operations. DAP is 
significant for an early file access protocol in its ability to provide ran- 
dom access to a wide variety of different file structures. Figure 3-9 
illustrates the use of DAP to access directory information across a 
DECnet. 
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$ dir/full cats::*, 
Directory CATS: : SYSS$COMMON: CDECNET] 


ATLANTASPRINT. DAT: 1 File ID: None 

Size: 38/38 Owner: (376,376) 

Created: 13-NOU-1987 88:08 Revised: 13-NOU-1987 08:88 (1) 

Expires: <None specified> Backup: ZI3-MAY-1988 87:07 

File organization: Sequential 

File attributes: Allocation: 38, Extend: @, Global buffer count: 
Version limit: @ 

4 Record format: Variable length 

Record attributes: Carriage return carriage control 

Journaling enabled: None 

File protection: System: RVED, Owner: RWED, Group:RE, World: 

Access Cntrl List: None 


- 
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ATLANTASPRINT. MAP; 1 File ID: None 

Size: 6/76 Owner: C376, 376] 

Created: 14-DEC-1987 10:36 Revised: 14-DEC-1987 18:36 (1) 
Expires: <None specified> Backup: Z29-MAY-1988 07:07 

File organization: Sequential 

File attributes: Allocation: 6, Extend: @, Global buffer count: @ 
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Fig. 3-9 Using DAP to access directory information. 


DAP is being gradually supplanted by the Phase V Distributed File 
System and by other remote data access mechanisms such as the 
Local Area VAX Cluster. The File Transfer Access Management 
(FTAM) pieces of OSI are also an alternative to the DAP protocols. 
DAP protocols still provide higher performance than DFS and other 
complex protocol suites over low-speed dial-up lines. In _high- 
bandwidth environments, the LAVC and DFS mechanisms can provide 
up to 5 times the performance of the DAP protocols. Obviously, a key 
element of the DAP protocols is their longevity, which means that a 
large number of applications have been coded to take advantage of 
them. 

A DAP session consists of a series of messages exchanged between 
the DAP server and the DAP client. Each message consists of an 
operator (or packet header) and an operand (or packet data). The 
operator can consist of up to seven fields. Operand structure depends 
on the command chosen. Figure 3-10 illustrates a series of DAP mes- 
sages over an Ethernet link. 

The operator begins with a type field. These type fields can be DAP 
defined or user extensions. The next field consists of a series of flags 
which indicate if the next five parameters in the operator are present 
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Fig. 3-10 DAP traffic on an Ethernet link. 


or missing. This field also contains a MORE bit which signals the 
presence of more data in subsequent packets that form one segment. 

A stream ID field is used when a single user transmits multiple 
streams of data. This does not mean that multiple users can share one 
logical link. This is because each DAP session must run in the 
authorization context of the remote user to prevent unauthorized ac- 
cess to information. 

Two length fields are available. If a single-length field is used, up 
to 256 bytes can be contained in a message. If the second-length field 
is used, between 256 and 64,000 bytes can be contained in a message. 
If an acknowledgment is sent, it often consists simply of a type field 
and nothing else. This 1-byte acknowledgment helps increase the ef- 
ficiency of DAP data transfers. 

The last two fields in the operator are the bit count and system- 
specific fields. A bit count field is used when the last byte of a data 
message has some unused bits in it. The system-specific environment 
is used only in homogeneous environments, such as one VAX RMS file 
system talking to another VAX RMS file system. If a DAP message 
containing system-specific fields is received in a heterogenous environ- 
ment, it causes a fatal error and termination of the session. 
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It is possible to multiplex several DAP messages into a single ses- 
sion control buffer. If this option is used, length fields are required. 
The length fields enable the DAP process to demultiplex a single data 
message into each of the logical data streams. 


Configuration messages 


To begin a DAP session, configuration messages are exchanged be- 
tween the two systems. This message establishes the maximum buff- 
er sizes, operating system type, and file system type. The configura- 
tion field also contains a system capability bit map that has an ex- 
haustive list of different capabilities. When each of these bits is set, it 
indicates that the system has that capability. Figure 3-11 illustrates a 
DAP configuration message. 

After a configuration message, the session usually exchanges access 
and attribute messages. An access message establishes the type of 
access requested, and an attribute message defines the type of data in 
the file or the type of data needed. 

The access message specifies a file name and the type of access re- 
quested. Access types can be used to open a file or a create a file. 
Users can also specify management functions needed, such as renam- 
ing or erasing a file. Finally, a special type of access is a directory 
list, which will return a list of file names. 

The access message also specifies what to do in the case of errors. 
It is possible for users to proceed upon encountering I/O errors or to 
return a fatal error message. The user can also specify that status 
messages be sent when data is accessed. 

A special type of access is the go/no-go option. When a user 
specifies that they want to delete a file, and that file has a wild card 
in it, it is possible that the operation will refer to several different 
files. With the go/no-go option, the name of each file accessed is 
returned to the requesting process. The requesting process can then 
indicate continuation of the operation with a RESUME flag in a CON. 
TROL message. Alternatively, the user can issue a SKIP flag in a con- 
trol message to move to the next file. Figure 3-12 illustrates a data 
access message using the DAP protocols. 

A further function in the access message is the type of access level 
that the user will be requesting of the file. This allows the specifica- 
tion of reads, writes, deletes, updates, or to perform block I/O. The 
process can also specify the type of shared access it is willing to ac- 
commodate—the ability of other users to read, write, delete, update, or 
perform other operations. The combination of the two types of access 
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Fig. 3-11 A DAP configuration message. 


can then be translated into a VMS lock. The clusters chapter of this 
book has a discussion of VMS lock compatibility tables. 

The last function of the access message is to indicate the types of 
attributes the user is interested in retrieving for this particular access. 
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Code = Z2 (Attributes) Operand Length = 11 
Attribute Data Type: ASCII Data 
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Attribute Record Format 
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FB$SQ0; Sequential access only 
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Access Function = $OPEN; Open existing file 
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IYO errors are non-fatal 
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File Name Specification = ‘’SYS$SYSROOT: CSYSEXE] DUDRIVER, EXE; 5” 
File Access Type: 
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Fig. 3-12 DAP data access message. 


The user can request any combination of summary data, file protec- 
tion, access control information, date and time created, or other infor- 
mation typically available in a VMS environment. 

An attribute message would be returned in response to an access 
message. In the case of a directory listing, the operation may end 
after the last attribute message is received. In the case of a data 
access operation, the attribute message may be followed by several 
data transfer messages. 
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Attribute messages describe, in great detail, the structure of the file. 
The type of data can be left undefined or can specify ASCII, EBCDIC, 
compressed, or other options. Files can be organized as sequential, 
hashed, or indexed in various ways. The record format can be 
specified as fixed, variable length, or a single stream of ASCII data. 

Other attributes of a file include a series of file access options. This 
allows a user to specify that a file be rewound when it is opened or 
closed. The user can also specify that contiguous space is needed for a 
file or that a particular file is locked. Several file operations are 
meant to address a magnetic tape environment. 

Other file access options deal with concurrency issues. Files can be 
signaled as locked, and users can signal that they are willing to wait 
for a currently locked file. Waiting for a currently locked file is 
analogous to the asynchronous system trap (AST) locking option in a 
single system or clustered environment. As can be seen, DAP maps 
most single-system file operations into a networked environment. 

A final set of file access options determines the disposition of a file 
at the end of a session. The end of the session could be a normal DAP 
termination or the result of a node or network failure. Temporary 
files can be deleted upon closure or can be spooled to a line printer. A 
file can even be submitted as a command file when it gets closed. 

The last set of attributes for a file is the device characteristics. This 
list includes support for mailboxes, real-time devices, and network 
devices. Devices can be signaled as mounted or allocated, terminal or 
file oriented, sharable or spooled. 


Control messages and data access 


Once the access and attributes are established, the user can perform a 
series of control operations on the file. These allow the user to delete 
data, request blocks of data, or set and release locks. Commands are 
provided to flush all data through the protocol stack to ensure that 
there are no outstanding messages. Control messages also are used to 
control the position within a file—the user process can issue com- 
mands to move forward or backward within the file or to find a par- 
ticular record in a random access file. 

The actual transfer is done via a data message. The data in this 
message is totally transparent and can consist of binary data, al- 
though there’s no guarantee that the receiving system will know what 
to do with that data. A PC can use DAP to bring a VAX-executable 
image to the PC disk. This does not mean that the VAX program will 
run very effectively on the PC operating system. 
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Several other messages allow the extension of certain types of at- 
tributes. The date-time attribute extension message is used to trans- 
fer the date and time that a file was created, modified, or last ac- 
cessed. Key definition attribute extension messages are used to define 
keys on remote files. Protection and access control attributes allow 
remote manipulation of a file’s security attributes. 


DAP operation 


The DAP exchange begins with the link being set up by passing 
authorization information down to the session control layer. The ses- 
sion control layer may accept a user ID, a password, or an account 
identification. The remote session process will then activate a DAP- 
speaking process to run in the user’s authorization context. DNA can 
include a default account for users that do not furnish access informa- 
tion. 

On a VAX running VMS, the processing of providing files to remote 
users is accomplished with a File Access Listener (FAL). The FAL is 
a DAP-speaking process that negotiates with the local instance of the 
Record Management Services (RMS). The DAP-speaking process 
transfers the data across the network. The local user then sees the 
data as though it were furnished locally. This is because the RMS 
services shield the user from the location of the data. Figure 3-13 
illustrates the relationship of RMS to File Access Listeners on remote 
nodes. 

Original DAP implementations required a separate DAP-speaking 
process for each file accessed. Needless to say, wild-card operations on 
files became highly inefficient. Current implementations of DAP are 
multithreaded, allowing a single user the ability to access multiple 
files. The stream ID function allows data and attribute messages to 
apply to a particular file. 

During normal operation, a status message is returned with each 
message sent. During the data transfer process, it is possible to omit 
success status messages until after the completion of the file transfer 
process. 

When errors occur in I/O processing, the remote DAP-speaking 
process typically suspends processing and sends a warning status mes- 
sage to the user process. The user then can send a control message to 
indicate whether to resume data transfer or to terminate the access. 
These options can also be set in the initial access configuration mes- 
sages. 

Data transfer operations can operate either on sequential or direct 
access files. In a sequential file retrieval, a single GET control mes- 
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Fig. 3-13 File access listeners. 


sage is issued. This is followed by the transmission of all records in 
the file without further DAP messages. It is the responsibility of the 
lower layers of the network to perform flow control during this phase. 
Streaming of data across the network stops when an end-of-file or 
error occurs. It is also possible for the receiving process to abort the 
transfer. 

Aborting the transfer is done by sending an access complete mes- 
sage. The process that issued the access complete may still receive a 
considerable amount of data if the network has a large store of buf- 
fers. 
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Sending a sequential file to a remote location is very similar to get- 
ting one. A single PUT control message is issued, followed by a series 
of data transfer messages. The system that is storing the file con- 
tinues to accept data until it receives an access complete message. 

Record level access proceeds in a more complex manner. For each 
record accessed, the user submits a CONTROL message which contains 
a GET command along with a key value. This is followed by the 
return of the desired record. The issuing program issues another con- 
trol message and receives the next record of data. The meaning of the 
key depends on the type of access that was requested—a key value 
has a different meaning for the different structures of random access 
files. 

Accessing directory information is done by first issuing a directory 
list command. This may contain a series for wild cards in the file 
name field of the access message. A directory list access command 
results in a whole slew of return messages. The return message 
begins by issuing a name message, which contains a volume or device 
name. This is followed by a second name message which contains the 
directory specification. Next, a third name message contains the 
name of the first file. This is followed by a series of attributes of that 
file, depending on the ones that were requested in the access message. 
Then, the next file name is transmitted, followed by another set of 
attribute messages. At the end of the process, an access complete 
message is sent. 

DAP is a highly sophisticated file access mechanism, considering the 
age of the protocol. It specifies a great number of different options 
that are used to access most VMS file systems and other file systems 
used on the other DEC operating systems. In a sense, DAP hard- 
codes the different options available by making long lists and exchang- 
ing long configuration messages. 

A series of more modern approaches are available and are discussed 
later in this book. The OSI FTAM protocols, for example, build a vir- 
tual model of a file store. This virtual model is then encoded in a 
variety of presentation contexts which allow dissimilar systems to ex- 
change data. The definition of the format for that data transfer can be 
negotiated using a combination of presentation layer facilities. This 
allows a wider variety of systems to interconnect. 

The Data Access Protocol is the original Phase IV service used for 
the exchange of data across the network. The Distributed System Ser- 
vices, discussed later, are gradually supplanting the use of DAP-based 
services. 

DAP is a protocol used by two cooperating processes to define the 
exchange of data. The NSP protocols together with the session control 
layer allow the exchange of messages. These messages, however, con- 
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tain no semantic information on the type of data. DAP builds on top 
of these lower-layer services to add more complex concepts such as 
indexed data or file protection codes. 

On a VAX system, all requests for data are typically intercepted by 
the Record Management Services (RMS). If the request is for local 
data, RMS uses a QIO system call to request data from the local 
device driver. That local device can be a locally attached disk or even 
a disk attached to an HSC controller in a cluster. 

If the requested data is not local, RMS redirects the call, still using 
a QIO system service, to the network. The remote session control 
layer receives the request for data and activates a File Access Lis- 
tener. A FAL is a DAP-speaking process which cooperates with the 
local instance of the Record Management Services. The FAL process 
acts as an agent for remote nodes to deliver data. 

The exchange of data using the DAP protocols can be fairly complex. 
The procedure begins with the exchange of a set of configuration mes- 
sages. These messages establish the parameters of the DAP session, 
such as buffer sizes, file system type, and operating system type. 

Following the basic configuration, the DAP-speaking processes can 
exchange information about the attributes of files being accessed. 
This information may include file organization, device characteristics 
(tape, disk, etc.), and the format or data records. 

The originating DAP process can then request a certain type of ac- 
cess to a file. This access could be read, write, or delete. This is 
followed by a data exchange phase. The DAP protocols include 
provisions for the establishment of a data stream, status messages, 
and data stream termination. 

The DAP protocols also include several provisions for more complex 
information about files. Key definitions of remote files can be re- 
quested and data can be accessed at the record level by index values. 
This record level access makes the DAP protocols more than a simple 
file server. 

Usually, the DAP protocols are used in the Record Management Ser- 
vices. It is possible to write user programs that access DAP directly 
through the Network File Access Routines. A Network File Transfer 
utility is also available, an interactive utility used to access DAP- 
speaking processes. 


Distributed Naming Service 
The Distributed Naming Service is a lookup service that separates the 


logical name of an entity from its physical location. This is the same 
service that is provided with VMS logical names but is extended into a 
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distributed network environment. Sets of names, called directories, 
can be located in multiple locations on the network. When a host or 
user encounters a need for a service, it is able to contact a nameserver 
to find out who is providing that service. 

DNS is a service that will be used at two levels of the network. At 
the session layer, DNS replaces the need for a local node database 
that contains translations of node names to DNA addresses. In a 
Phase IV network, adding a new node to the network meant updating 
the local databases of every node that would need to access the new 
node. In Phase V implementations, a new node registers itself with 
DNS and all other nodes on the network are thus made aware of its 
presence. 

The second use of DNS is by upper-layer services. DNS can be used 
by a message-handling system to provide locations of electronic mail 
users. Another use is to provide transparent access to files located 
throughout the network. 

Each type of name, such as file name or node name, is stored in a 
directory. A directory may have child directory entries to add further 
structure to the definition of a type of service. 

At the bottom of a directory tree is a series of object. Each object 
has a name and a set of attributes. The session layer node name 
directory, for example, would have an object named Nodename with 
an attribute called DNA Address. 

A special type of name is called a soft link. This is a pointer to an 
object someplace else in the directory service. An object name must be 
unique—it can be stored in only one place in the directory structure. 
Soft links allow an object to be referred to by multiple names or 
aliases. Figure 3-14 illustrates a DNS namespace. 

The namespace is the collection of all directories. A network usually 
has only one namespace. It is possible for development or transition 
purposes to have dual namespaces, but each namespace is totally dis- 
tinct. The namespace has a namespace unique identifier (NSUID). 
Usually, a nickname for the namespace is defined on each node in the 
form of a logical name. 

Each name in the namespace has internal and external repre- 
sentations. An internal representation of the name is provided for 
program-to-program communication, as in the case of client programs, 
protocols, and databases. 

An external representation is used for the user interface. The exter- 
nal representation consists of the NSUID (or a nickname which is 
translated into the NSUID) plus a list of simple names that together 
uniquely identify the object. Each name (representing a directory, 
child directory, object, or soft name) is concatenated together. For ex- 
ample, the namespace DEC might have a directory representing files, 
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Fig. 3-14 A DNS namespace. 


which has subdirectories which has individual files in it. This might 
be represented by the syntax: 


DEC:FILES.MY_ SUBDIRECTORY.FILE1 


The complete list of the hierarchy provides a unique name. Note 
that there might be multiple instances of FILE1, but only one may 
exist in the subdirectory MY_SUBDIRECTORY. Names in DNS are case 
sensitive. If a space or a period is contained in an object name, it 
must be delimited by double quotes. 


Object attributes 


All names in the namespace have a series of attributes. Global at- 
tributes are present in all kinds of entities including objects, direc- 
tories, soft links, and child directories. Each type of entity, such as an 


DNA Upper-Layer Protocols 73 


object, also has a series of class-specific attributes. An attribute can 
be single valued or can consist of a multivalued attribute set. 

Global attributes include a unique ID for each object and an update 
time stamp which signals when this entity was last modified. All ob- 
jects also include an Access Control Set. The Access Control Set is a 
multivalued attribute which consists of a set of Authorization Entities. 

Objects have a type-specific attribute called object class. Two 
predefined object classes are the clearinghouse and the group. 
Clearinghouse objects are lists of collections of nameservers. The 
nameserver thus uses its database to manage itself. 

A second predefined class is the group. The group consists of a list 
of single objects or other groups of objects. A program operation Test- 
Group can test one of these objects to detect loops in groups. A loop 
would occur when a group object has itself as one of its own members. 

Directories also have a series of type-specific attributes. The 
Replicas attribute contains a set of clearinghouse objects. This at- 
tribute specifies all clearinghouses that participate in providing a 
name service for this particular directory. The AllUpTo attribute is a 
date up to which all updates and modifications to this directory are 
guaranteed to have been applied. 


Replicas and Partitions 


The namespace has two important characteristics. It is partitioned, 
meaning that different directories of a namespace can be stored on 
different nameservers, and it is partially replicated, meaning that a 
particular directory may reside in several different locations. 

A clearinghouse is a particular set of directories located on a 
nameserver. A nameserver may actually have several different 
clearinghouses that it manages. If a clearinghouse is inactive, it is 
unable to service client requests. Active clearinghouses are available 
to provide the name service. 

Replicas of directories may be located at several different clearing- 
houses. A replica is an instance of a particular directory at a par- 
ticular clearinghouse. One of the replicas is considered the master; 
others are secondary replicas. Both master and secondary replicas 
can accept updates. The single instance of the master is used to pro- 
vide certain overhead functions that don’t need to be duplicated. 
Other replicas may be designated as read-only replicas. 

It is important to understand that a nameserver does not guarantee 
the accuracy of the results it provides. This loose consistency guaran- 
tee is because updates may be made in several places and must 
propagate through the namespace. At any one point a query to dif- 
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ferent nameservers may result in different answers. Over time, the 
different replicas are guaranteed to converge. 

A special process called a skulker is responsible for providing the 
convergence among replicas. A skulk runs in the background and can 
be configured to run at different time intervals depending on the criti- 
cal nature of the particular directory it is updating. A skulk can also 
be manually initiated by a client. Figure 3-15 shows the different 
modules of a DNS implementation. 

The skulk begins by forming a virtual ring. Each replica of the 
directory has a pointer to one other replica. Together, all of the 
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replicas form a ring. If the ring cannot be formed, two different 
skulks have been initiated at the same time. It is important that all 
instances of the directory contain the same information so only one 
skulk can run at a time. 

Once the ring has been closed, the skulker on the initiating node 
goes to every master and secondary replica and gathers all updates 
that have been made since the last skulk. These are applied to the 
local clearinghouse, then propagated to the other replicas. Finally, 
the AllUpTo pointer is updated on every replica as of the time of the 
beginning of the skulk. 

While the skulk works in the background, there are several other 
processes that form part of the nameserving environment. A clerk 
runs on every machine on the network. The clerk makes the name 
service available to client programs, such as the DNA Phase V session 
layer or a distributed file system. In order to improve performance, a 
clerk maintains a cache of recently accessed entries. 

Each clerk is responsible for knowing about the existence of at least 
one nameserver. Clerks send solicitations to learn about the existence 
of a nameserver. Servers also periodically send out service advertise- 
ments to signal their availability. 

A clerk interacts with a transaction agent. The agent is responsible 
for accessing clearinghouses on behalf of the clerk and performs entity 
creations, updates, deletes, and lookups on the local clearinghouse. 
The transaction agent also coordinates directory operations and com- 
municates with other servers using a special directory maintenance 
protocol. 

When an update is made, the transaction agent notifies an update 
module. The update module is responsible for notifying the update 
listeners on other nodes that instances of the relevant directory have 
been changed. The update listener on each node then performs the 
updates as needed. 

Update modules work in conjunction with the skulker. The update 
module handles immediate updates while the skulker handles deferred 
updates and provides a higher degree of consistency checks. Note that 
the update modules are multithreaded and can handle multiple con- 
versations with other update modules throughout the network. 

Update senders make known the presence of a new clearinghouse. A 
clearinghouse name is an object in a directory that is replicated at 
every node, so the new clearinghouse is created on one node and the 
update sender notifies listeners on every other node. Since the 
presence of this type of high-level namespace information is impor- 
tant, this particular directory has an attribute which indicates that 
other nodes have a persistent need to know about updates. When a 
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new clearinghouse is added, all other nodes are informed about this 
new collection of replicas. 

Security in the namespace is maintained through a series of 
Authorization Entries. These entries can apply to individuals or to 
groups. Groups can consist of other groups. 

Each particular entity has flags for read, write, delete, test, or con- 
trol over that entity. Control is the ability to change the attributes 
such as access control. Entities can also have propagation control, 
which determines how to propagate access control to lower layers in 
the namespace. 


Distributed File System 


The Distributed File System is an application similar to the DAP 
protocols discussed earlier. Because DFS is more modern than DAP, 
it provides a significantly higher degree of performance with an 
equivalent level of functionality. DFS allows a foreign file to appear to 
the user as though it were local. Thus, rather than referring to a local 
file DISK1:FILENAME, the user can refer to a file DFS1:FILENAME. 

DFS differs from the DAP services in that users do not have to 
know the location of the information they are looking for. In the DAP 
protocols, users must specify a filename in the syntax 


NODENAME::DEVICE_NAME:FILENAME. 


DFS allows users to strip off one level of the name, the node, and 
refer to all files as though they were local. DFS also allows files in 
multiple locations to appear as though they resided on the one DFS 
device. DFS, like the NFS services discussed in the TCP/IP chapter, 
allows the user to treat the network as one transperant file system. If 
a network administrator moves the files, DNS allows the user to 
remain unaware of the change in physical location. 

DFS has some similarities to VAX Clusters and the distributed file 
system that is part of that architecture. They both provide 
transparent access to files. The cluster file system, however, is limited 
to members of the cluster. This is because the cluster provides a high 
degree of concurrency to users, including write sharing on files. DFS 
requires that a write lock on a file be exclusive, but is not limited to 
members of the cluster. 

DFS takes a local system and makes it available to the network. 
This is done by designating a particular portion of the local file system 
as an access point. An access point can be a device name, a directory 
name, or a subdirectory name. The DFS server informs a DNS 
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nameserver of the existence of an access point and maps it to its node 
name. 

Once an access point is defined, it becomes a virtual file system for 
access on remote nodes. A local node then mounts that access point to 
make it part of a virtual local file system. Note that this virtual local 
file system may consist of local files, files available through a cluster 
environment, files available through DAP protocols, and files available 
through the DFS service. The Record Management Services is able to 
determine the type of file referred to and notify the appropriate ser- 
vice provider. In the case of a local file, the service provider is a local 
class driver which is able to accept QIO requests to read and write 
data. In the case of the DFS services, the service provider is the DFS 
entity which also accepts QIO requests. 

Servers are able to accept requests for normal file operations, in- 
cluding reading and writing blocks of data. File management opera- 
tions include the ability to create, open, and close. Directory opera- 
tions include lookups, creation, and deletion. Finally, file management 
operations such as allocating blocks to the file or reading or changing 
the file header are also available. 

The DFS is a connection-oriented service, unlike the Network File 
System. A logical link is maintained at the end of an operation and 
only deleted after a fairly long time-out period. This reduces the over- 
head in accessing data by not requiring the creation of a logical link. 

A connection-oriented service has the potential disadvantage of 
causing the file system (RMS) to return errors when the service 
provider is temporarily unavailable. Rather than immediately return- 
ing an error message to the user program, the DFS is able to retry the 
operation. Up to five retries, each one occurring every 15 seconds, can 
occur before an error message is sent to the user. 

A special feature of the DFS is when a remote file system actually 
belongs to a cluster. Several nodes of the cluster could potentially 
provide access to data through the second level of distributed files, the 
cluster file system. If a mount operation to a member of a cluster 
fails, the DFS client is able to immediately try another cluster mem- 
ber and remount the file system. 

Security in the DFS environment is a function of the security 
scheme on the server. Users are authenticated through the use of 
proxy accounts. It is fairly important that the user space consist of a 
flat namespace. That is, no two users should share the same name. 
Otherwise, the security system may fail. 

DFS is restricted to exclusive locking at the file level and shared 
read access. If a user attempts to lock a file at a lower level (remem- 
ber—this is a transparent file, so a program could easily issue this 
request), the DFS server automatically provides an exclusive lock. 
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Special-purpose files, such as installed files in VMS or swapping and 
paging files, are unavailable in a DFS environment. 


Distributed Queuing Service 


A related utility to DFS is the Distributed Queuing Service. This ser- 
vice makes remote printers available across the network. The printer 
can be located on an Ethernet, as in the case of the LPS40 or on a 
host. Additionally the print queue may be on a particular host, but 
the actual printer may be available via a LAT connection to a terminal 
server. 

DQS is not really a printing utility. Its function is to take a job from 
one queue and place it in another one. This mechanism could thus 
work on other queue types such as batch queues. Batch queues are 
not included in DQS for security and accounting reasons. 

DQS examines each queue and looks for jobs and resubmits them on 
the target queue. Queues can be daisy chained together. The notifica- 
tion facility makes sure that the original submitter of the job is 
notified of completion or abortion. 

A symbiont is a process which accepts information from a queue and 
moves it over to a printer. Symbiosis is the process of bringing two 
worlds together and the VMS symbiont brings disk-based data over to 
the world of printer-based data. DQS operates in a flexible manner 
because VMS separates the function of queue management from 
processing the items on a queue. 

The link between queues and symbionts is provided by a VMS sys- 
tem level process called JOB_CONTROL. This process takes the top 
item off a queue and then calls a program to run. For batch queues, 
the program to run is the job on the top of the queue. For print jobs, 
the JOB_CONTROL calls the symbiont. 

Since any symbiont can be tied to a queue, the DQS service is com- 
patible with the various types of printer drivers, including those writ- 
ten by users. DQS is also used to pass application-specific flags 
through to the symbiont. A symbiont for an LPS40, for example, 
might accept a variety of flags from DQS and then use a new DNA 
logical link to request access to the LPS40 located on the Ethernet. 

User-written symbionts may at first glance seem a waste of 
programming resources. To make the need for this facility more ap- 
parent, imagine 6000 students all enrolled in an Introduction to PL/1 
class. It is a law of nature that a substantial portion of those students 
will decide to print out their executable images to see what they look 
like. What they look like is a lot of pages on the floor. A user-written 
symbiont could very easily decline to process those types of files. More 
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Fig. 3-16 VTX Videotex software. 


sophisticated uses are for devices with complicated setups, such as 
plotters. 


Videotex 


Videotex is an interactive system which allows a user to download 
several pages of information to a local terminal (or local node acting as 
a videotex terminal) and then peruse these pages at their leisure. 
DEC’s VTX product is compatible with the CCITT F.300 standards for 
videotex systems. Videotex systems provide the user with interactive 
access to information. That information is distributed transparantly 
in the network and is accessed using a consistent, hierarchical menu 
structure. Figure 3-16 illustrates the main screen for DEC’s VTX 
software. 

A variety of different terminals are supported, including the Prestel 
terminals and French Minitel series. Also supported are the DEC VT 
series, the IBM 3270 terminals, and the DECtalk voice output system. 
A user of a VT-series terminal can use a local node to buffer pages and 
thus appear as a multipage videotex terminal to the system. 

A VTX infobase consists of multiple pages of information that are 
structured in a hierarchical fashion. DEC uses this system internally 
for distributing pages of manuals to sales staff. Each of the pages can 
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consist of mixed text and graphics and a request for data can lead to 
multiple pages of data. 

In addition to the database of information, the VTX system can in- 
clude links to other applications. These applications may be already 
written and complete in themselves, or they can be written to take 
advantage of VT'X-like capabilities. 

A VTX environment has two types of users. End users, or sub- 
scribers, access the infobase or applications that are linked to it. 
These users may access VTX through X.25 networks, from SNA en- 
vironments, or from anywhere on a DECnet. 

Information providers are people who maintain and develop the in- 
formation bases. DEC provides a special tool called the VTX Infobase 
Structure Tool and Assister (VISTA) which allows the information 
provider to develop a storyboard layout and build menu structures. 

The VTX server is able to access both an infobase and applications 
that are tied to the server. Infobases are stored in RMS files and are 
thus accessed using the RMS file access services. If the information 
requested is not locally maintained, the VTX server is able to contact 
other VTX servers to find the information. 

Foreign applications are tied into remote applications using an in- 
terface library called the External Link Interface (ELK), which is a 
protocol library for accessing servers over DECnets. This requires the 
user to manage all context for a user session. ELK is able to accept 
keywords from a VTX server and deliver them to the application. The 
application delivers a series of pages, which are delivered to the VIX 
server, which then forwards them to the user. 

The VTX Application Service (VAS) builds on top of ELK to provide 
additional functionality. VAS is able to collect user responses, make 
flow control decisions, and display pages for users. VAS is built on a 
request-response protocol and is able to accept remote connections 
from applications over DNA, SNA, and X.25. Because VAS uses mul- 
tiple simultaneous contexts, it is used for applications with multiple 
request and response users. 

ELK-based programs are often used to provide information to the 
update servers, which in turn add the information the infobase. If the 
ELK application is located on a remote node, it needs to use a remote 
update server link module. This allows the VIX update modules to be 
extended over the DECnet facilities. 

The terminal-specific modules are used to provide concentrator sup- 
port for X.29 virtual devices and for 3270 class terminals. 
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Summary 


The DNA Phase IV services discussed in this chapter provide a full- 
featured set of network capabilities. They make the network look like 
a simple extension of the individual node. Remote files appear local, 
either through DAP protocols or with the distributed file service. 
Remote nodes can be logged into using the CTERM protocols. 

DNA Phase IV began in 1980 and at the time was widely considered 
to be the most modern commercial network software available. 
Despite its functionality, DNA Phase IV has several limitations that 
have led to other architectures. The Local Area Transport Architec- 
ture, for example, deals with the potential inefficiencies of CTERM in 
handling large amounts of nodes in the Ethernet environment. 

Another architecture, the System Communication Architecture, sup- 
plements DNA by allowing highly concurrent, highly efficient access to 
data in a VAX Cluster. While DFS and DAP function well in a full 
DECnet, their generality leads to some decrease in potential perfor- 
mance. SCA, by contrast, is able to work very efficiently, but only 
with a limited number of nodes. 

The next chapters of this book consider these alternative DEC- 
developed architectures in detail. After the architectures are 
presented, Part 3 describes how these various architectures are imple- 
mented into actual networks. Local area networks are first con- 
sidered, followed by wide area networks. Then, the question of im- 
plementing DNA on particular operating systems and managing the 
network is considered. 


For Further Reading 


Benson et al., “VTX and VALU—Software Productivity Tools for Dis- 
tributed Applications Development,” Digital Technical Journal, 
February 1988, vol. 1, no. 6, p. 80. 
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al Specification,” version 5.6.0, AA-K177A-TK 
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Chapter 


Direct Ethernet Clients: 
LAT and MOP 


Overview of LAT and MOP Protocols 


The DNA protocol stack provides a general layered network service 
that is able to adapt to a variety of different network topologies. In a 
local area network environment, however, the DNA protocol stack can 
introduce needless overhead. This is particularly true in the case of 
the CTERM protocols, which require each character to be sent in a 
separate packet. While this is efficient for wide area networking 
scenarios, it does not function well in a LAN environment. 

The Local Area Transport architecture is meant to address a very 
specific problem of terminals communicating to hosts over an Ether- 
net. Because of its limited scope, the LAT architecture is able to 
bypass the session, transport, and routing layers and make direct use 
of the Ethernet. The LAT architecture multiplexes user data headed 
for the same destination into a single packet. The LAT architecture 
also off-loads much of the terminal services management function 
from the host, freeing up CPU cycles for other types of computation. 

Another direct Ethernet client is the Maintenance Operations 
Protocol (MOP). One purpose of these protocols is to downline load 
operating systems into a remote device that does not have any mass 
storage facilities. Since DNA is a fairly complicated set of software 
modules, it is unreasonable to expect that the diskless node has the 
capability to make DNA requests. Instead, the MOP protocols are 
used, which consist of a very simple set of services that can be built 
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into the read-only memory of a device. As will be seen, although MOP 
is technically part of the DNA architecture, it operates in a different 
fashion from DNA services examined previously. 

MOP is used for a large number of different devices by DEC. Disk- 
less VAXs are one example of a device that uses MOP. General-pur- 
pose servers, such as terminal or communications servers, also use the 
MOP protocols. In all three cases, the operating system for the device 
is kept on a Phase IV host on the Ethernet. When the diskless device 
is initialized, the first thing it does is broadcast a request for an 
operating system on the Ethernet. A Phase IV host then responds by 
downline loading the operating system to the device. Once the device 
is intialized, it uses another architecture such as LAT or DNA to per- 
form further network functions. 


Local Area Transport Architecture 


Terminal servers are important in a VAX Cluster because one of the 
goals is to allow a user on a given terminal to access any one of 
several hosts. DEC originally wanted to put terminal servers directly 
onto a CI bus cluster. CI bus hardware was expensive enough to 
make DEC look for an Ethernet-based solution. The search for a 
cheaper link was also the impetus for the Ethernet-based Local Area 
VAX Clusters (LAVC). 

The DECnet CTERM protocols would provide one possible solution 
for terminal access. Terminal servers would just be dedicated DECnet 
nodes, much like the Ethernet-based DECnet Router. CTERM could 
rapidly saturate an Ethernet because every character is sent in a 
separate packet. Because an Ethernet packet must have at least 46 
bytes of data and because echoing means that each character typed 
uses two packets, CTERM is not an efficient solution. 

The other solution is to use a system that is similar to the public 
X.25 networks. Rather than send each character off in a packet, mul- 
tiple characters (possibly from multiple users) are saved and sent off 
together. In X.25, this is the function of the X.3 Packet As- 
sembler/Disassembler (PAD). For terminals on an Ethernet, DEC 
LAT protocols perform a similar multiplexing function. 


Local Area Transport protocols 


There are two layers to the LAT architecture. A virtual circuit layer 
provides a link to all hosts that the terminal server is communicating 
to. Establishment of a virtual circuit takes only one message ex- 
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Fig. 4-1 LAT data packet. 


change. The virtual circuit layer provides a data transport service for 
the slot layer. By default, every 80 milliseconds (ms) the virtual cir- 
cuit layer sends off a packet. This parameter can be adjusted by the 
network manager to be 30 milliseconds or greater. Studies have 
shown that a good touch typist begins to have problems if the echo 
delay is greater than 100 ms. Figure 4-1 shows LAT data on an 
Ethernet. 

If a virtual circuit packet is not acknowledged within the circuit 
timer parameter, (usually 80 ms), the server assumes that there is a 
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problem. Rather than compound an existing network saturation prob- 
lem or a high transient load on the CPU, the server waits for ap- 
proximately 1 second. After a user-set number of retries, the server 
assumes that the host (or network) has crashed. 

If there is no data to send, the virtual circuit goes into a balanced 
mode. This means that either side can reinitiate transmission if it has 
data to send. In the normal unbalanced mode, only the server in- 
itiates the data exchange. In balanced mode, a KEEPALIVE message is 
sent every 20 seconds. Otherwise, no data is sent. 


Slot layer 


Built on top of the virtual circuit layer is the slot layer of LAT. The 
slot layer has three functions. It establishes user sessions, multiplexes 
sessions over a virtual circuit layer, and provides a transparent data 
transfer access service to users of LAT. 

The maximum slot size is 255 bytes. The slot size can be different 
for each side of a connection. The terminal side would have a typist 
and would only need a small slot size. The host side might be sending 
full screens of data and could thus use a larger slot size. 

Between the terminal server and the host, LAT uses a credit sys- 
tem. Each side of a session is independent, allowing full duplex opera- 
tion at the slot layer even though the underlying virtual circuit is a 
request-response system. Each side in a session can typically have up 
to two credits outstanding. 

LAT uses five different kinds of slots. START and STOP slots are 
used for session control. An ATTENTION slot is used for out-of-band 
signalling. These three types of slots are not subject to credit limits. 

The other two slot types are A and B slots. A slots are used for data 
transfer. B slots are used for transmitting physical port and session 
characteristics. 

A single packet at the virtual circuit layer can contain several slots. 
By combining several characters per user in a slot and several users 
in a virtual circuit packet, the LAT architecture multiplexes data be- 
tween the terminal server and a particular host. 


Service advertisements 


In addition to virtual circuit and session-related messages, LAT also 
has a third kind of message called a service advertisement. Every 
host willing to accept terminal sessions is a service provider. All ser- 
vice providers multicast the availability of their service and a current 
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service rating every 60 seconds. Figure 4-2 illustrates a LAT service 
advertisement. 

A node might provide multiple types of services. Thus a machine 
could be a member of a cluster and thus offer a CLUSTER service. 
That node might also have some special-purpose graphics software not 
available on the rest of the cluster and could broadcast the availability 
of a GRAPHIC service. 

When a user makes a service request and there are multiple 
providers of that service, the terminal server logs the user on to the 
node with the best service rating. On a VMS system, the LTDRIVER 
process uses four factors to calculate a service rating, including the 
most recent CPU idle time, the CPU type, the amount of memory, and 
the number of interactive slots left. 

Service ratings provide a fairly sophisticated form of load balancing. 
The system manager is also allowed to set a static service rating for a 
node. This can be used to allow a “hot” backup service. Normally, 
users are logged onto a production system which has a high service 
rating. A backup node is given a lower service rating. If the produc- 
tion system crashes, the backup node becomes the offerer of the ser- 
vice. 

Service providers can be assigned a LAT group code. This can be 
used to partition an Ethernet into several different environments. 
Users would only see the services that pertain to their group. 


Reverse LAT 


A reverse LAT capability allows a terminal server to provide services 
instead of just using them. This is typical in three situations: 


» Connection of modems 
a Connection of non-LAT hosts 
a Connection of printers 


Modems on a terminal server can be dial-in or dial-out. Dial-in 
modems are just an extension of the terminal. Dial-out modems, how- 
ever, are used by the host as a peripheral device. Often, a set of 
modems need to be offered in a rotary. The rotary allows the host to 
refer to modems as a generic service and the service provider, in this 
case the terminal service, to log the user onto the first available 
modem. 

Often, there is a need to connect a user of the DECnet to a foreign 
host. One solution to this connectivity problem is to have both hosts 
on DECnet, TCP/IP, or some other network architecture in common 
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with both systems. If there is no common networking solution, how- 
ever, a possible solution is to use a reverse LAT capability with the 
foreign host. 

Most systems provide support for asynchronous terminals. The 
reverse LAT solution entails connecting an RS-232 cable from the 
asynchronous ports on the host to ports on the terminal server. Users 
wishing to connect to the foreign host then request a service, which 
connects them to the appropriate port of the terminal server, which in 
turn passes the user through to the foreign host as though they were a 
directly attached terminal. 

Asynchronous printers are a third use of the reverse LAT function. 
Print queues are logically connected from the host to the terminal 
server port with the printer. Multiple systems can share one printer, 
although only one host can have a virtual connection active with a 
particular printer at one time. It is also possible to define a printer 
service which consists of several printers configured in a rotary. 


Host transparency 


To the host, the incoming session from a terminal server consists of a 
virtual terminal port. The terminal class driver deals with this virtual 
port just like it would a locally connected terminal. Each session gets 
a unique slot number and all data for that session is identified by that 
slot number. 

LAT, CTERM, and other network-based virtual terminal protocols 
allow a host to treat all incoming sessions the same way. This is im- 
portant because it means that individual pieces of software do not 
have to first determine if the session is remote or local. DEC ac- 
complishes this on a VMS system by using a two-level device driver. 
When software sends data, it sends it to a terminal class driver. The 
class driver is used for all terminal applications. Figure 4-3 illustrates 
the two level device driver. 

The terminal class driver, in turn, hands off the data to a particular 
device driver based on the type of connection. For a LAT server, the 
host sends the data down to a LAT driver. If the session is a CTERM 
process, it sends the data to the CTERM driver, which in turn hands 
it down to the lower layers of the network stack. If the terminal is 
locally connected, the terminal class driver hands the data down to a 
physical device driver. 

The LAT architecture is able to off-load a significant portion of host 
overhead for terminal services management. There are two kinds of 
directly connected devices, those that use direct memory access (DMA) 
and those that use a character interrupt scheme. Under heavy loads, 
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Fig. 4-3 Two-level terminal driver. 


LAT provides better performance than either type of asynchronous 
communications controller. 

Under very light loads, a non-DMA character interrupt system 
provides better performance. A DMA controller on the system re- 
quires polling and is thus inefficient with a very sporadic load. With a 
bigger load, the DMA controller becomes more efficient because the 
increased number of interrupts helps justify the polling overhead. 
With a large number of users, the LAT architecture is significantly 
more efficient than either DMA or character interrupt devices. 

Although LAT servers are best when there are multiple sessions 
over one virtual session, its use is also frequently justified in single- 
node implementations. This is frequently the case when a PC with an 
Ethernet controller uses the LAT protocols instead of DECnet to pro- 
vide access to a host. Services such as load balancing are provided 
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and LAT can provide block transfer of data coming back from the host, 
in contrast to the asynchronous nature of the CTERM protocols. 

LAT drivers exist for VMS, RSX, Ultrix, and even the Tops 20 
operating systems. LAT terminal servers are available from DEC and 
a few third-party providers such as Emulex. LAT implementations for 
PCs are available from DEC, Polygon, and other companies. PC LAT 
implementations are a supplement to DECnet/DOS in that they allow 
the user to choose among multiple service types. 


Maintenance Operations Protocol 


The Maintenance Operations Protocol (MOP) is technically part of the 
Digital Network Architecture. However, most maintenance functions 
cannot assume the presence of the other portions of the network, such 
as a routing layer or session control module. MOP thus works directly 
with the data link layers and bypasses the rest of the networking 
protocol stack. In this sense, MOP cannot be considered to have the 
same status within DNA that the other layers do. 

MOP is used in conjunction with other protocols on the network. 
MOP might be used for downline loading an operating system. After 
that, the network management protocols (NICE) are used to exchange 
management data, and the DNA protocols are used for exchanging 
higher-level information (See Figure 4-4). 

There are three major functions provided by the MOP protocols. A 
communications test function is used to see if a data link layer is 
operative. A system console function is used to provide console tasks, 
such as a remote operator function. Finally, a load-dump function is 
used to transfer directly to and from remote processor memory. 

MOP is a high-performance, low-overhead client of the data link 
layer. It assumes minimal processing power on remote systems. In 
many cases, the MOP client is a diskless CPU that is using MOP to 
boot itself over the network. MOP is able to work with both DDCMP 
and Ethernet data links. The CI bus can also be used as a data link 
layer. 

MOP operates in a client/server mode. Requesters are the clients in 
the relationship and they control the MOP operation. Servers may be 
known, or in the case of the Ethernet, a general appeal for help may 
be broadcast. A server will then volunteer to service the request. 

The data link layer is assumed to provide two types of services: 
framing and error checking. In the case of Ethernet, there is only 
minimal error checking. Both DDCMP and the CI bus provide packet 
acknowledgment. Since Ethernet is relatively error free, there is real- 
ly no need for the type of checking done in a DDCMP environment. 
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Fig. 4-4 MOP and other DNA protocols. 


Remote booting 


The typical use of MOP is for booting a diskless node. This can be a 
router, a MicroVAX, an SNA gateway, or any of a variety of different 
servers on an Ethernet. This can also include a VAX connected to an 
HSC controller on a CI bus. Remote boot operations can also be used 
on a dedicated DDCMP line. 

Since the device requesting the remote boot may have no disk 
drives, the MOP protocols are built into read-only memory (ROM). 
The node transmits a request load service message. In the case of the 
Ethernet, this requires another node to volunteer assistance. The re- 
questing node not only requests the service but specifies the type of 
file that it is requesting. The server then checks to see that this is a 
valid load request before volunteering assistance. 

The load operation typically occurs in several stages. The primary 
loader in ROM is able to request that a secondary loader be put into 
memory starting at a certain memory address. Usually, the secondary 


Direct Ethernet Clients: LAT and MOP 93 


loader is able to request that a tertiary loader is put into memory at 
another address. Finally, the tertiary loader requests that the operat- 
ing system itself is loaded. 


Remote console function 


The remote console function is used to control nodes on a network. 
Typically, low-level operations must be done only on the console of a 
system. Thus, requesting that a frozen system reboot itself is usually 
accomplished by executing a special key sequence that gives the user 
access to low-level functions on the CPU, bypassing the operating sys- 
tem. The remote console function allows these operations to be per- 
formed remotely. The remote console function allows a single operator 
to manage multiple remote devices, such as MicroVAXs or terminal 
services. Figure 4-5 illustrates the remote console function. 

The user (i.e., the Network Control Program) first requests that it 
become the console for a remote system. There can only be one con- 
sole active on a system at one time. All requests to reserve the con- 
sole to a remote system or for remote boots are subject to a 4-byte 
verification check by the target system before they are honored. 

In addition to forcing a remote boot, the console function can be 
used to perform two other functions. The system ID and type can be 
requested. This includes the type of communications device, such as 
an Ethernet controller. It also includes the type of processor, such as 
a communications server. 

Finally, the console can be used to read a variety of low level 
counters. For example, the console can request the number of send 
failures and the failure reasons from an Ethernet controller. Failure 
reasons might include a frame that was too long, excessive collisions, 
or block check errors. 


Summary 


The Local Area Transport mechanism provides an efficient method to 
connect terminals to an Ethernet via a terminal server. The CTERM 
protocols provide another capability to perform the same function. In 
addition, there are several other alternatives for connecting terminals 
to hosts that will be examined. 

Two of the other alternatives are to use X.25 or TCP/IP to connect 
terminals to hosts. Since a terminal cannot be connected to a net- 
work, in both cases a terminal server is used to connect to the net- 
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Fig. 4-5 A MOP packet on Ethernet. 


work. In the case of TCP/IP, the terminal server functions much like 
any other computer using the TCP/IP protocols. 

For X.25, a special set of LAT-like protocols are used with an X.3 
Packet Assembler/Disassembler (PAD). The PAD buffers characters 
typed in and then sends off the packet when it is full, a time-out 
counter expires, or certain special characters are encountered. A spe- 
cial character might be a carriage return or function key. 

LAT differs from other packet-oriented transport services in several 
respects. It uses a request-response connection management rather 
than the usual symmetric connection. Message exchange is timer 
based rather than event driven. Finally, service availability can be 
multicast. 

In addition to network-oriented methods of connecting terminals, it 
is important to consider other alternatives such as the use of a PBX. 
In this scenario, the network is not used to connect terminals. In- 
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stead, the network is used for machine-to-machine communications. 
The PBX provides a separate front-end network for connecting the 
user device to a particular host. 

A third alternative is to move from terminals which cannot be part 
of a network to intelligent user workstations. A PC with DECnet/DOS 
is an example of such an approach. Another approach is to use the X 
Windows System protocol discussed in the last part of this book as a 
way of connecting bit-mapped graphics workstations to various com- 
pute servers on the network. 

The MOP protocols, like LAT, are also direct users of the Ethernet. 
A terminal server from DEC will use both sets of protocols. MOP is 
used to initialize the device and downline load the terminal server 
software. Included in the software that is downline loaded are the 
software modules that process the LAT protocols. 


For Further Reading 


Digital Equipment Corporation, “DECnet Phase IV Maintenance 
Operations Functional Specification,” AA-X436A-TK, December 
1983. 


Mann et al., “Terminal Servers on Ethernet Local Area Networks,” 
Digital Technical Journal, vol. 1, no. 3, September 1986, p. 73. 
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Chapter 


Clusters 


Overview of Clusters 


Clusters are a cross between a parallel processor and a network. Like 
a single system, a cluster shares a common file system and has high- 
speed communication between processors. Like the network, there are 
multiple instances of the operating system and a system of inter- 
process communication instead of the shared memory of the parallel 
processor. Figure 5-1 shows the characteristics that clusters have in 
common with networks and parallel processors. 

There are two kinds of clusters. A CI Cluster uses a very high- 
speed network at the physical and data link layers. This CI bus 
operates at 70 mbps, in contrast to the 10 mbps of the Ethernet. A 
Local Area VAX Cluster (LAVC) uses the Ethernet as the data link 
layer. Both types of clusters use the System Communication Architec- 
ture and have the same functionality. 

Nodes in a cluster consist of either a VAX or an HSC controller. 
The HSC controller is a special purpose computer that has up to 32 
disk drives connected to it. An LAVC has only VAX systems, while 
the CI bus can have a combination of VAXs and HSC controllers. 

There are three primary benefits to a cluster. First, there is high 
availability. Disk drives can be volume shadowed and dual ported in 
case of either disk or controller failure. Multiple VAX systems can 
access file systems providing a degree of fault tolerance in case of 
processor failure. 

The second benefit is modularity. Disk drives, controllers, and 
processors can be independently upgraded. A cluster can have the 
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Figure 5-1 Networks, clusters, and parallel processors. 


processing power of one VAX 11/780 or can be as powerful as 
hundreds of 11/780s using a cluster of 8840s. The LAT architecture 
for terminal servers makes this look like one big computer through the 
mechanism of service providers. Each member of the VAX Cluster 
provides the same service, and the terminal server logs the next user 
onto the service provider with the highest service rating. 

Finally, clusters provide a very high-performance method of data 
sharing. The file system is transparent to users. In the case of the CI 
bus clusters, throughput for data access can be as high as two Mbps. 
Even with the Ethernet-based LAVC, file access is 10 times faster 
than the older Decnet DAP protocols. This high-performance file sys- 
tem is coupled with a relatively efficient distributed lock manager to 
provide full concurrency in the distributed file system. | 

Although an LAVC-based file system is faster than a DECnet, it is 
still not as fast as a local file system. Usually, an LAVC would be 
used for applications that are fairly compute intensive. A CAD/CAM 
system, for example, would fetch a diagram and then an engineer 
would work for a long period of time on that diagram. An LAVC 
would allow the engineer to use a diskless workstation. The worksta- 
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tion is obviously cheaper because of the lack of a disk, but it also 
avoids many system management problems associated with dis- 
tributed backup over a network. 


Cl bus hardware 
The CI Bus is a 70 mbps bus which connects nodes of a cluster using a 


star configuration. The star coupler is a passive device which can ac- 
commodate up to 24 nodes. A node is any device that has a CI con- 
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troller, which means a VAX with a BI bus or Unibus, or a Hierarchical 
Storage Controller (HSC). Figure 5-2 illustrates the component of a 
CI bus Cluster. 

Connecting individual nodes to the star coupler are four pieces of 
coax cable, up to 45 meters (m) in length. The four cables provide 
separate send and receive paths, with dual paths for each function. 

The HSC is a PDP-11-based system that functions as a Digital 
Storage Architecture-compatible disk controller. Because it is also a 
stand-alone computer, the HSC can service requests from multiple 
VAX systems. The HSC70 can have up to 32 tape and disk drives 
connected to it. Burst speeds of 3.25 Mbps can be accommodated from 
any one drive and the HSC has an internal data bandwidth of 13.3 
Mbps. 

Individual disk drives can be connected to two HSC controllers. 
This provides dual access paths to the data. In many configurations, 
disk drives use volume shadowing so that every change to one copy of 
the data is automatically reflected on a mirrored volume on another 
disk pack. Dual ports and volume shadowing together provide a de- 
gree of fault tolerance against either HSC or disk failure. Dual copies 
of the data also increase retrieval speed. Since volume shadowing 
takes place on the HSC controller, it requires little intervention from a 
host CPU. Figures 5-3 and 5-4 show an HSC controller and a star 
coupler. 

User access to the cluster is usually through some form of data 
switch that attempts to balance the load among multiple CPUs all 
offering the same service. This could be a simple data switch with a 
rotary capability. The switch picks the next available line and con- 
nects the user to it. Because the lines are interleaved, this provides a 
form of load balancing. 

The LAT protocols used by terminal servers provide a more sophisti- 
cated way of performing load balancing. All members of the cluster 
periodically broadcast the availability of a service type along with a 
service rating. The service rating is a function of idle CPU time and 
the number of available log-in slots. The terminal server evaluates 
each connect request by a user and connects it to the service provider 
with the best service rating at that time. 

Because the cluster forms a common system from the users point of 
view, it also makes sense to create the same unified system from the 
point of view of the system manager. Clusters allow a common 
security and management domain, as well as a common monitoring 
interface. Figure 5-5 illustrates the use of the VMS monitor utility on 
multiple cluster nodes. 
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Fig. 5-3 HSC 70 and 50 storage controllers. 
System Communication Architecture 


The System Communication Architecture is a different networking ar- 
chitecture from the Digital Network Architectures. In most cases, 
both DNA and SCA will be used together. Often, the Local Area 
Transport Architecture (LAT) will also be used. It is possible to have 
all three networks share the same Ethernet. 

The SCA has two main layers. The System Communication Ser- 
vices (SCS) provide a software layer for internode communication. 
SCS can be though of as providing a transport layer akin to the NSP 
protocols in the DNA architecture. 

System Communication Services provides for three types of services. 
A datagram is an unacknowledged packet up to 576 bytes long. This 
is used by upper-layer services that provide their own guarantees of 
delivery. Most disk read and write operations are transmitted in the 
form of datagrams. 

Messages are up to 112 bytes long and are always acknowledged. 
Messages are used, among other things, for SCS control information. 
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Acknowledgment is immediate as the CI port retains control of the 
bus long enough to send the reply back. 

Block data transfer is used for transfer of information greater than 
4000 bytes. This is a guaranteed delivery of information from the 
memory of one node to the memory of another. For long transfers, 
this method can achieve throughput of 2 Mbps on the CI bus. The CI 
port has direct memory access and thus requires very few CPU inter- 
rupts for fairly extensive data transfer operations. 

Below the SCS is a data link layer, consisting either of a CI bus or 
an Ethernet. A routing layer is not present because all nodes are 
always one hop away from each other. The physical media depend on 
the data link protocol used. For the CI bus, only a coax cable is sup- 
ported. For an LAVC, Ethernet supports five types of media including 
broadband, baseband, ThinWire, twisted pair, and optical fiber. 

Above the SCS layer are a variety of service providers. These ser- 
vice providers are programs on each node of the cluster that communi- 
cate with each other over virtual circuits provided by the SCS. An 
example of a service provider is the connection manager, which detects 
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Fig. 5-5 Monitoring multiple cluster nodes. 


state transitions in the cluster configuration. Another service provider 
is a distributed file system that allows multiple nodes to all request 
I/O services from multiple HSC controllers. 

Every node in a cluster has a special service provider known as the 
SCS$DIRECTORY. This application keeps a list of all services offered 
within the cluster. Thus, a file system wishing to know the cluster 
address of all disk servers (MSCP$DISK) would consult the SCS$DIREC- 
TORY for that information. 


Connection Management 


Each member of a cluster has a service provider called the connection 
manager. Together the connection managers ensure that the cluster 
does not become partitioned. A partitioned cluster means one device 
participates in two different clusters. An HSC controller might be 
part of two different systems. Since the lock manager on each cluster 
is in charge of synchronizing all access to data, two different lock 
managers mean that there is a very real possibility of data corruption. 
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The connection manager maintains a virtual circuit to all other 
members of the cluster. The connection manager also regularly polls 
other nodes to keep a current list of members. A state transition oc- 
curs when a node leaves the cluster (a virtual circuit fails) or enters 
the cluster (a new node is connected). During transition periods, all 
cluster processing stops. 

In the case of a virtual circuit failure, it may be some temporary 
problem. Before declaring a cluster transition, the connection 
manager waits for a system-manager-set period of time to elapse. If 
the time-out period elapses, a coordinator node is elected to guide the 
members through the transition period. 

The coordinator proposes a configuration for the cluster. All other 
nodes must agree with this proposed configuration. If no agreement is 
reached, the coordinator backs out. Another node can then attempt to 
become coordinator with its proposed configuration. Once a configura- 
tion is agreed upon, the coordinator leads other nodes through the 
process of rebuilding the distributed lock space. 

Because cluster processing does stop during transition periods, the 
cluster cannot be considered to be fault tolerant in the sense of com- 
puters such as those made by Tandem. Cluster reformation time can 
take several minutes in some configurations. 


Distributed Lock Manager 


The lock manager in VMS is implemented independently of the file 
system. This allows other systems, such as database management 
software, to implement their own types of locks. 

Locking is performed on a hierarchical resource tree. A lock ona 
higher part of the tree applies to all lower parts of the tree. A disk 
volume might consist of the top of the tree. The next level of the tree 
would be an individual file. A page of data would be a lower level and 
an individual record would be a leaf node on the resource tree. 

One of the key questions in designing a file system is locking 
granularity. Since locks consume resources and take time to obtain, it 
is more efficient to lock large amounts of data for any one application. 
However, this reduces the concurrency of the system by making that 
data unavailable to other users. 

A database vendor might wish to synchronize access to data at the 
table level or the tuple level (the equivalent of a record). Some DBMS 
vendors also provide locking at the page level. Each page may contain 
several tuples of data. Keeping the file system independent with the 
lock allows implementation of systems with different levels of locking 
granularity. 
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In VMS, the lock manager uses the same code for single-node opera- 
tion as is used for a distributed cluster environment. Software sys- 
tems, such as the file system, issue ENQUEUE and DEQUEUE calls to 
the lock manager. An ENQUEUE call queues a lock request. A DE- 
QUEUE call releases the lock on a resource. 

The call to the lock manager can be of two different types: request- 
response or AST. A request-response call is either granted or denied 
at the time it is processsed. The other option is to set an 
asynchronous system trap (AST). If the resource is unavailable, the 
request is queued and the calling process is notified when the resource 
becomes available. 

When requesting a lock, the calling process can also request a block- 
ing AST. This means that the process is notified when some other 
process wants the resources in some way that is incompatible with the 
present lock. A blocking AST allows the process with the lock to avoid 
constant calls to the lock manager. While holding locks with a block- 
ing AST may be optimal during periods of low use, during periods of 
high use many systems switch back to the request-response protocol. 

The lock manager defines a variety of different kinds of locks in 
terms of their compatibility with other forms of locks. Each particular 
lock has no set definition, but a suggested meaning is supplied and is 
usually used for file-oriented applications. Figure 5-6 shows the lock 
compatability table and their suggested interpretations. 

Applications may frequently start out with one type of lock and then 
decide they need another. A user reads a record of data and then 
later may decide to update it. Rather than releasing existing locks, 
the lock system allows a user to convert a lock to a different type. A 
convert operation may be denied if an incompatible lock on the 
resource already exists, or the request may be queued and an AST 
requested. 

In a cluster, the lock manager is distributed across the different 
VMS nodes in the cluster. Distributing the lock manager reduces the 
overhead on any one node and frequently allows the node that wants 
to use a resource to perform local locking rather than generating SCS 
messages. 

Each resource, such as a disk volume, has a resource manager. Re- 
quests for locks on the resource, whether issued locally or from 
another node, must be directed to this resource manager. If the re- 
quest for the lock came from another node, it also keeps track of locks 
it has obtained. 

Because resource managers may change, the locking system also 
provides a directory service. The connection manager keeps a list of 
all nodes in the cluster and the resources they provide directories for. 
If a node wants a lock, it first finds the location of the directory ser- 
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vice. It then asks the directory node who is managing the resource. If 
no node is managing the resource, the directory tells the requesting 
node to manage the resource itself. Figure 5-7 shows the three mes- 
sages needed to obtain a lock. 

During a cluster transition, the lock space is rebuilt. This means 
that all systems release all foreign locks. The locks are then reac- 
quired one by one. During this rebuild process, a different resource 
manager may be appointed. The possibility of a new resource 
manager means that lock management functions do not eventually all 
migrate to the oldest member of the cluster. 

One potential problem in a lock manager is deadlock. Deadlock, 
often called a “deadly embrace,” arises when two processes are each 
waiting for each other to finish a certain task. Deadlock detection is 
fairly expensive and is only initiated after a time-out period. If dead- 
lock is detected, a victim is arbitrarily selected to break the embrace. 

Deadlock can happen easily when many locks at the bottom of a 
resource tree are converted to a higher-level lock. For example, if a 
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Fig. 5-6 VMS lock types. 
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process acquires a dozen record-level locks, it may decide to try to 
convert those dozen locks into a single table-level lock. 

Another conversion is from shared to exclusive locks. Two processes 
may both have concurrent read locks on a piece of data. Process A 
may then request that it be granted an exclusive lock on the resource. 
An EX lock is incompatible with process B’s existing CR lock. Process 
A therefore queues its convert request. Process B also requests an EX 
lock, which is incompatible with process A’s CR lock. Each process 
ends up waiting for the other to finish. 

The second kind of deadlock is also a deadly embrace, but in this 
case two different resource managers are involved. This is a much 
more difficult situation to address. After the possibility of a convert 
deadlock is ruled out, the system begins looking at all locks held by 
other processes that the time-out process is waiting for. The deadlock 
detection code then tries to trace their locks back to the first process. 


GET LOCK 


GET DATA E> 


N 
HS: 


CP KINES EN NON IN 
coe a beet? aa he ee 
a N NEN AN 


9 
RRR US 
yaratetatetatetatetatetatetetetetetstatetatetetetatstete® 


Fig. 5-7 Finding and locking a resource. 
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CLUSTER LOCK PERFORMANCE 
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Fig. 5-8 Lock performance data. 


It is interesting that both DEC and IBM use the same algorithm, inde- 
pendently arrived at, to detect this form of deadlock. 

Performance of the lock manager does add a significant amount of 
overhead in a clustered environment because of the extra trips that 
are taken over the CI bus or Ethernet to gain permission to lock a 
resource. Often, this increase in lock-time performance is more than 
offset by being able to share a high-performance disk drive and con- 
troller over multiple nodes. Figure 5-8 shows the difference in perfor- 
mance between a local and remote locking operation. 


Distributed File System 


Most of the synchronization issues that must be resolved for a file 
system are dealt with in the lock manager. The file system under 
VMS can thus operate without regard to the clustered environment. 
Implementation of file management functions, such as security, space 
allocations, and other issues are done using an Extended QIO Proces- 
sor (XQP) which is present on VMS nodes. 

Devices that are cluster accessible use the Mass Storage Control 
Protocol (MSCP), a message-oriented set of protocols for access to 
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data. The message-based system allows multiple hosts to queue data 
requests on a single controller. More traditional register-oriented con- 
trollers allow several processes on one node to access data because 
that one node was able to queue and synchronize the requests. An 
MSCP-based device takes over that function from the host system. 

XQP makes extensive use of locks for synchronization purposes. For 
example, a volume synchronization lock is taken out when a volume is 
mounted. When a particular instance of an XQP needs to allocate 
more space for a file, a protected write (PW) lock is requested. This 
allows other XQP processes to continue their read operations, but they 
would not be able to simultaneously allocate the same space to 
another file. 

Locks are also used at the file level to provide synchronization. Any 
user attempting to open, close, extend, delete, or otherwise affect a file 
is issued a PW lock on that file. This ensures that file operations 
occur in a serial fashion. 

In VMS, a series of five different caches are used to reduce the I/O 
operations associated with file management by almost 75 percent. For 
example, a file control block list contains the attributes of all open 
files and recently referenced directories. An extent cache holds copies 
of free disk space and is used for quick allocation of new space. A 
quota cache eliminates much of the overhead associated with quota 
management. 

A significant issue in cache management is the possibility of cached 
data becoming out of date because of an operation performed by 
another node in the cluster. Associated with each lock is a 16-byte 
space called a value block. This value block is a way of passing infor- 
mation between different lock users. 

When a resource is changed, the file system updates the value block. 
Often, a node will release its locks but continue to cache data. To 
check the validity of this cached data, the ncde can request a lock at 
the appropriate level. When the lock is granted, the XQP compares 
the value block on the new lock with the value block associated with 
the cached data. If the values are different, the XQP knows that the 
cached data was not valid. 


Distributed Queuing Systems 


In a cluster, the user is usually not aware of what node they are 
logged onto, especially if they use the LAT services to request a 
generic type of service. Printers and batch queues, however, are as- 
sociated with a particular node on the cluster. Since the user does not 
usually care on which node a print or batch job is executed, the dis- 
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Fig. 5-9 Global print and batch queues. 


tributed queuing systems provide a generic resource controller, which 
farms out work to specific print or batch queues. 

Print and batch queues both operate the same way. An input file is 
placed in a designated subdirectory and the job is put into a queue 
with a particular priority. When the queue controller decides to 
process that particular file, it sends it either to a printer or as a 
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process to be computed. Upon completion, the user is optionally 
notified. Figure 5-9 shows the queueing mechanism. 

A queue is first initialized on the local machine. Next, a cluster- 
wide queue controller file is created. Finally, individual queues are 
joined to the cluster-wide queue. 


Local Area VAX Clusters 


Local Area VAX Clusters have the same functionality as a CI bus sys- 
tem, with three important performance-related differences. First, the 
CI bus which operates at 70 mbps is replaced by an Ethernet which 
operates at 10 mbps. Secondly, the System Communications Services 
is implemented in software on the MicroVAX instead of the CI control- 
ler as it is for a CI bus. This means that the CPU must perform tasks 
previously off-loaded to a controller. 

Finally, the HSC controller is replaced by a MicroVAX, which per- 
forms these functions in software instead of in a dedicated processor. 
This MicroVAX is known as the boot member of the LAVC. A com- 
bination of the CI bus and the Ethernet, known as a Mixed Intercon- 
nect Cluster, does allow an Ethernet-based VAX to access the services 
of an HSC controller. 

An LAVC is usually used for compute-intensive applications such as 
CAD/CAM, some integrated office automation environments, or 
desktop publishing. Usually, though not always, members of an LAVC 
are VAXstations and make intensive use of graphics for the user inter- 
face and the display of data. 

LAVCs replace the function of the CI port with a port emulator. 
This is a software process that emulates the SCS interface on a Cl 
port. The software then reformats the information for transmission on 
the Ethernet. 

Although the Ethernet and the CI bus both operate at the data link 
layer, there are important differences between the two. Ethernet does 
not have the capability to send different kinds of messages, nor does it 
provide for automatic acknowledgment of data. Of course, there is also 
a significant difference in performance between the two media. The 
port emulator must therefore mask these differences from higher-level 
processes that use SCS, such as an MSCP server or a connection 
manager. Figure 5-10 illustrates data access in an LAVC environ- 
ment. 


112 DEC Networks and Architectures 


USER 
APPLICATION 


DISK CLASS 
E DRIVER 


MSCP ! 
SERVER 


‘SYSTEM 
COMMUNICATION 
SERVICES 


SYSTEM 
COMMUNICATION 
SERVICES 


ETHERNET 


DISK PORT 
DRIVER 


Fig. 5-10 Data access in an LAVC. 
Boot nodes 


There are two kinds of nodes in an LAVC that operate in a sort of 
client/server relationship. A boot node provides management func- 
tions and has a disk drive with the cluster common files. Satellite 
nodes are clients of the boot node and use it for disk drives, printers, 
and distributed batch processing. Figure 5-11 shows boot and satellite 
nodes on an Ethernet. 

A boot node can require substantial disk space and CPU resources 
in a large cluster. A boot node must be at least a MicroVAX II with 
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Fig. 5-11 An LAVC configuration. 


150 Mbytes of storage. This boot node can only service three satellite 
nodes, and they would probably need local disk drives for paging and 
swapping. A cluster can have two boot nodes to reduce the bottleneck 
at a single CPU (usually at the Ethernet controller) and also to pro- 
vide some fault tolerance. 
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Satellite nodes 


Satellite nodes in a cluster usually boot themselves over the network, 
using the DNA Maintenance Operation Protocol (MOP). It is thus pos- 
sible to have no mass storage facilities on a satellite node. If a disk- 
less node is used, it is important that the node have at least 4 Mbytes 
of memory to avoid excessive paging and swapping over the Ethernet. 
Often, a satellite node might have a small laser printer and a 70- 
Mbyte local disk drive for local storage. It would then go to the client 
node for access to larger mass storage facilities and faster printers. 


Mixed Interconnect Clusters 


Although the original cluster implementation on the CI bus was 
limited to 16 nodes, the Systems Communications Architecture per- 
mits up to 224 nodes in a cluster. The original LAVC announcement 
only supported 13 nodes, which was later raised to 26. With the an- 
nouncement of VMS version 5, DEC also announced support for Mixed 
Interconnect Clusters. This allows up to 42 members in a cluster, of 
which up to 24 can be on a CI bus. These limits can be expected to 
gradually increase as DEC continues to gain experience with VAX 
Clusters. : 

Some studies have shown that it is actually quicker for a MicroVAX 
II to get data over a Mixed Interconnect Cluster than to go to a local 
drive such as an RD53 Winchester disk. This is because the HSC 
controllers and associated disk drives are so much quicker that the 
intermediate time spent on transmitting data through the CI Bus and 
the Ethernet plus all the intervening software layers is recovered. It 
is important to note that these results are highly application depend- 
ent. 


Availability and Performance 


In a Local Area VAX Cluster the limiting factor is usually the ability 
of the boot node to process both CI port emulation code and MSCP 
server code. With a fast CPU, the next bottleneck becomes the speed 
of the Ethernet controller. The next bottleneck is Ethernet saturation, 
reached at the rate of roughly 100 typical I/O requests per second. 

A common configuration is to use an Ethernet bridge to segment the 
members of an LAVC from other members of the larger network. The 
bridge allows connectivity to a backbone network but keeps local traf- 
fic on the work area network. When there is extensive I/O activity on 
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the LAVC, a segmented Ethernet allows the work group to degrade its 
local performance without affecting the rest of the network. 

Two types of issues seem to limit the performance of a cluster. 
First, locking is considerably slower in a cluster environment than 
with local locking. If the directory node is not known and there is an 
existing resource manager, it takes four messages to receive a lock. 
Even if the resource manager is known, such as in the case of a con- 
vert operation, it still takes two messages to receive a lock. The 
bandwidth of even a CI bus is significantly slower than that needed 
for a local lock operation within main memory. 

The most significant performance implication of clusters seems to be 
in cluster reformation time. The rebuilding of a lock space and estab- 
lishing the connection managers can take seconds and or even minutes 
to accomplish. This is a significant processing pause in a busy en- 
vironment. For this reason, a cluster is known as a high availability 
instead of a fault-tolerant computing environment. 

With enough resources, losing one node in a cluster will not result 
in re-forming the cluster. This means that the lapse in service can be 
minimized. Of course, the node cannot immediately rejoin the cluster 
or cluster processing would have to stop so a new cluster could be 
formed. Thus, in a fairly stable environment, reforming clusters does 
not become a major issue. 


Census Bureau Clustering Case Study 


An interesting example of the use of clusters can be found in the Cen- 
sus Automated Processing System (CAPS) used by the U.S. Census 
Bureau to manage data it collects. CAPS consists of a series of 
clusters located throughout the country. The initial VAX Cluster was 
installed in Suitland, Maryland. 

The cluster itself consists of two VAX 8700 processors connected to 
four HSC70 controllers. Fourteen of DEC’s SA482 disk clusters are 
connected to the HSC processors for a total of 35 gigabytes of disk 
space. 

It is important to distinguish a disk cluster from a VAX Cluster. 
The disk cluster allows multiple disk drives to share a set of inde- 
pendent parallel spindles. In a normal disk drive, a single spindle 
provides access to the data. With multiple spindles, if one is busy, the 
other can access the disk drive to get the data. While an individual 
spindle on the SA482 has an average access time of 32 ms, the com- 
bination of multiple spindles provides average access times in the 
range of 20 ms. 
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Both of the VAX 8700 processors are connected to an Ethernet that 
is used to provide front-end access. Local user workstations consist of 
over 200 VT220 terminals as well as 80 VAXmates. The VAXmate is 
DEC’s PC/AT compatible system. 

Most of the data entry operations in CAPS are performed at another 
facility located in Jeffersonville, Indiana. Those users are connected to 
VT220 terminals, which are in turn connected to terminal servers. 
This configuration is linked to Maryland with a leased line on an ex- 
tended Ethernet. | 

The main purpose of the CAPS system is to process incoming census 
data, such as the agricultural, economic, and decennial censuses. For 
the economic and agricultural censuses alone, over 7 million forms are 
processed in Indiana. 

Data is stored in a relational database using DEC’s Rdb software. 
Once the initial data is entered, workers in Maryland are able to per- 
form a variety of validity checks to verify the data-entry operation. 
Data that is flagged as suspect is returned to Indiana for verification 
against the original paper forms. Over 60 different databases are 
maintained on the cluster for the different forms of data. 

The CAPS cluster in Maryland is the first phase. The eventual con- 
figuration consists of over 450 MicroVAX systems located around the 
country. In addition, a series of clusters will be located in field offices 
and at the headquarters site. 

The Maryland cluster illustrates nee VAX Clusters can provide a 
modular upgrade path. Disk drives can be added separately from 
HSC controllers, which can in turn be added independently of new 
VAX processors. Needless to say, the modular upgrade path does not 
alleviate the need for a balanced configuration. 


Summary 


Clusters provide a very important alternative to buying (or making) 
larger and larger systems. Important resources such as file systems 
and lock managers are shared in a coordinated fashion. Clusters do 
not provide shared memory such as a VAX 8840 would have with four 
CPUs, all having access to shared memory. The cluster instead func- 
tions like a conventional network, complete with a multilayered ar- 
chitecture. 

The most important benefit of clustering is a distributed file system 
that has full concurrency control. Most other file systems, such as 
DEC’s Distributed File Service and the Network File System do not 
have a limit on the number of nodes participating. However, this has 
been achieved at the expense of the locking services available. It is 
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important to remember that the distinction between clusters and other 
distributed file systems is beginning to fade as higher-speed data link 
mechanisms and distributed lock managers become available. 

The SCA architecture provides a complimentary set of services to 
DECnet. DECnet provides access to all nodes in a network, but this 
generality is at the expense of control and performance. The cluster 
environment provides a common management and security domain, 
but for a limited number of nodes. Clusters allow concurrent access to 
data with full locking capabilities. 

The LAVC environment uses the same architecture as a CI bus sys- 
tem, but at a significantly reduced level of performance. The Ethernet 
provides a raw bandwidth of 10 mbps as compared to the 70 mbps of 
the CI bus. In addition, the SCS internode communications functions 
are performed in software on the LAVC, whereas these functions are 
built into the CI controller on larger clusters. 

Because of the difference in performance, the LAVC is used for very 
different purposes than the large machine clusters. Large clusters are 
typically used by many users who desire rapid access to data in a 
transactions processing environment. The LAVC, by contrast, is typi- 
cally used by a few users on VAXstations. The applications of the 
LAVC are centered around graphics-intensive operations such as 
CAD/CAM or desktop publishing. The LAVC environment is used for 
infrequent access to large amounts of data. 

Note that these differences in cluster use are based solely on perfor- 
mance. The functionality of the systems is the same, and there is no 
reason why an LAVC could not be used for small transactions process- 
ing environments. 

Mixed Interconnect Clusters provide an important blending of the 
two capabilities. Because both the Ethernet and the CI Bus data link 
can be mixed in a common cluster, both VAXstations and large VAXs 
can share a common file system and a common management domain. 
Care should be taken, however, that node failures on the LAVC por- 
tion of the Mixed Interconnect Cluster do not result in a state transi- 
tion that stops processing for interactive users of the larger systems. 
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Chapter 


Local Area Networks 


Overview of Local Area Networks 


To the routing layer of DNA or the LAT processes, an Ethernet ap- 
pears as a single logical bus. This means that every node on the 
Ethernet is adjacent to every other node and thus does not involve any 
routing decisions. In reality, the configuration of this logical bus can 
be quite complicated. 

Ethernets can be implemented with a variety of physical media. 
Traditional coax cable, known as baseband, can be up to 500 m long 
with 100 nodes connected on it. Another type of coax cable, known as 
ThinWire, allows up to 30 nodes to be connected to a cable up to 185 
m long. Other Ethernet implementations might use broadband tech- 
nology, fiber optic, or twisted pair wires. Each of these instances of a 
physical medium corresponds to a single-segment Ethernet. 

Multiple segments, possibly consisting of different physical media, 
can be connected together with repeaters. A repeater takes every bit 
on a single segment, retimes and reamplifies it, and rebroadcasts it on 
another segment. Repeaters can be remote repeaters, allowing two 
segments to be separated by up to 1000 m of fiber optic cable. These 
multiple segments constitute a single Ethernet. 

An extended Ethernet allows multiple Ethernets to be connected 
together. Each of those Ethernets might be in itself a complex topol- 
ogy of mixed media and multiple segments connected with repeaters. 
The extended Ethernet consists of a series of Ethernets connected 
together with a bridge. While a repeater sends every bit over each 
segment, the bridge is able to determine if a packet of data needs to be 
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forwarded on the second Ethernet. The bridge thus allows connec- 
tivity while still segmenting the networks. 

Connected to the Ethernet are a series of servers. Obviously a serv- 
er can be a VAX or MicroVAX computer. Often, different VAXs are 
dedicated to different tasks such as database, graphics, document 
processing, or CAD/CAM. Another type of server might be a 
VAXstation that serves as the user interface. All of these different 
forms of computers are able to communicate at high speeds to form a 
coherent, cooperative network. 


Single-Segment Ethernets 


The basic Ethernet configuration consists of a segment of coax cable 
with up to 100 nodes on it. The segment can be up to 500 m long and 
is known as baseband or ThickWire. Connected to the Ethernet media 
is a transceiver. DEC’s H4000 transceiver is typical of most Ethernet 
transceivers. A vampire tap is used to make the connection to the 
media without cutting the cable. Figure 6-1 illustrates a basic con- 
figuration on an Ethernet. Figure 6-2 shows an H4000 transceiver. 

Ethernet is a broadcast media. Each node is able to send signals 
onto the cable. Those signals then propagate the length of the cable 
as a broadcast. In order to detect a collision, the Ethernet is ter- 
minated on both ends. This allows the signal to bounce back and al- 
lows nodes to detect any collisions with their original broadcast. 

Each host on the Ethernet has an Ethernet controller. These con- 
trollers are built into special-purpose devices such as terminal servers. 
For PCs, VAXs, and Macintosh systems, Ethernet controllers are an 
add-on peripheral. 

A controller needs to be compatible with the bus of the system it is 
going on. Thus, an Ethernet controller on a VAX 11/780 would need 
to be Unibus compatible, while a controller on a VAX 8800 would need 
to be BI bus compatible. The Ethernet controller joins other com- 
munications controllers on the host, such as asynchronous communica- 
tions controllers for connecting terminals. 

A tranceiver cable connects the transceiver to the Ethernet control- 
ler card. There are two grades of transceiver cable: low loss (BNE3x) 
and high loss (BNE4x). Low-loss cables can be up to 50 m long. High- 
loss cables are cheaper, smaller, and more flexible but can only be 12.5 
m long. 

Although a transceiver cable can be 50 m long, some of this length .- 
can be used up by the Ethernet controller. This is because a controller 
has an internal cabling equivalency. DEC recommends allowing 10 m 


Local Area Networks 123 


BASEBAND 
COAX CABLE 
TRANSCEIVER TRANSCEIVER 
CABLE 


ETHERNET 
CONTROLLER 


TRANSCEIVER 
CABLE 


Fig. 6-1 Connecting hosts to coax media. 


of low loss and 2.5 m of high loss as an internal cabling equivalency 
for most controllers. 

Transceivers on a segment of baseband are spaced apart in multi- 
ples of 2.5 m. Most baseband cables have a colored ring to show 
where these positions occur. The reason for the spacing restriction is 
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Fig. 6-2 WH4000 transceiver. 


that each transceiver introduces a certain amount of noise on the 
cable. By spacing the intervals at 2.6 m (or multiples thereof), the 
waves of noise generated by each of the transceivers cancel each other 
out. A second form of limitation on transceivers is that there can only 
be 100 transceivers on a single segment of baseband. 

A special form of transceiver is the multiport transceiver. DEC 
markets a multiport transceiver under the name of DEC Local Net- 
work Interconnect (DELNI). Up to eight individual Ethernet hosts 
can be connected to a single DELNI. The DELNI can operate in local 
mode which is commonly known as “Ethernet in a Can.” This is be- 
cause the DELNI takes the place of the Ethernet coax cable. Figure 
6-3 shows a configuration of nodes on a DELNI. 

In global mode, the DELNI is connected to the baseband segment 
using a transceiver cable and a transceiver. This means that eight 
devices that are close to each other don’t have to use up eight 
transceivers on the baseband with the required 2.5 m separation be- 
tween each node. 
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Fig. 6-3 Multiport transceivers. 


Each node on a global DELNI needs to be within 45 m of the 
transceiver that connects the DELNI to the baseband. This means 
that the transceiver cable connecting the node to the DELNI plus the 
transceiver cable connecting the DELNI to the baseband must equal 
45 m or less. The “missing” 5 m is because the DELNI is equivalent 
to 5 m of transceiver cable, just as some Ethernet controllers are 
equivalent to 10 m of cable. 

In a machine room environment, it is not uncommon to cascade two 
levels of DELNIs. This means that eight DELNIs are connected to a 
ninth DELNI. Up to 64 hosts can thus be connected without laying 
any coax cable, as long as each node is within 50 m of the top-level 
DELNI. 

Many organizations use Ethernet only as a method of connecting 
machine-room hosts together. A separate front-end network is used to 
allow PCs and terminals access to the machine room environment. 
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Fig. 6-4 DEC’s multiport transceiver (DELNI). 


This front-end network might be a data PBX. For these organizations, 
it is not necessary to lay cable and the DELNI is an appropriate solu- 
tion for an Ethernet because they can be rack mounted with other 


communications equipment in the machine room. Figure 6-4 shows a 
DELNI. 


ThinWire coax segments 


The baseband Ethernet media has several advantages. Its nonin- 
trusive tapping method means new nodes can be added to the network 
without disrupting service. Baseband is also fairly resistant to 
electromagnetic interference. On the other hand, it is fairly expensive 
and hard to handle. 

An alternative form of Ethernet cable is based on RG58, a thinner 
grade of coax known as Cheapernet or ThinWire. A single segment of 
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Fig. 6-5 DESTA ThinWire transceiver. 


ThinWire can only be 185 m long and can have a maximum of 30 
nodes on it. 

A different kind of transceiver is used for ThinWire connections. 
DEC sells one known as a DEC Station Adapter or DESTA. As with 
other ThinWire transceivers, these require that the cable be physically 
cut. The DESTA is then put in between the two segments. If a node 
is the last one on a segment, it puts a special terminator on the other 
side of the DESTA. Figure 6-5 shows a DESTA. 

Connecting the DESTA to the Ethernet controller is a standard 
transceiver cable. Usually, this is high-loss (but low-cost) cable. The 
length of the transceiver cable is restricted to a few feet. 

One problem with the DESTA is that if the DESTA is removed, 
there is an unterminated Ethernet. This disrupts service for every 
node on the ThinWire segment. The baseband segment, by contrast, 
has no problem if a node is removed because of the nonintrusive tap- 
ping method. 
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The problem of the unterminated ThinWire is not necessarily a 
hypothetical one. Most ThinWire nodes are personal workstations. 
When a user wants to move the workstation, the DESTA often seems 
to be the logical place to make the disconnection. The network 
manager may wish to invest in a supply of “high voltage” or “radioac- 
tive” stickers to place on the DESTAs in such areas. 


Broadband segments 


Broadband is based on the Community Antenna TV technology 
(CATV) used in cable TV systems. This CATV technology is meant to 
be hung on telephone cables and is thus highly resistant to salt, spray, 
and bird droppings. Each piece of CATV cable has a bandwidth of 300 
to 400 megahertz (MHz). This tremendous bandwidth means that 
broadband can serve the purposes of a number of communications 
technologies, including Ethernet, voice, and video. 

Broadband is often used as a backbone system between buildings in 
a campus-like environment. Because it is highly resistant to noise, it 
is also used in laboratories, factories, and electrically noisy offices. 

The topology of a broadband Ethernet is like a tree. At the head of 
the tree is a head end. Nodes send and receive at different frequen- 
cies on broadband systems. Nodes send data to the head end on a 
“reverse band.” The head end sends data back to the device on a “for- 
ward band.” The head end translates sending to receiving frequencies. 
A third frequency, known as the “guard band,” is used to separate the 
two data frequencies. 

Nodes connecting to broadband systems can use the same Ethernet 
controller and transceiver cable. ‘The transceiver is no longer an 
H4000 transceiver, however. Instead, a broadband modem is used to 
connect to the medium. It is called a modem because broadband is 
analog in contrast to the digital baseband medium. 

Broadband modems use particular frequencies on the CATV cable. 
Because of that, broadband modems on a single segment must all 
come from the same manufacturer. Chipcom Ethermodems and DEC 
DECOM modems are two examples of broadband modems. 

It is also possible to have dual CATV broadband cables. In this 
case, send and receive signals occupy different cables. The modem 
must be able to connect to a dual-cable broadband. 

Broadband has the significant advantage over ThickWire (the tradi- 
tional coax medium) of allowing segments to be 10 to 12 miles long. It 
is thus ideal in an extended local area environment. Many sites are 
using fiber as an alternative to broadband. This is because fiber has a 
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potential bandwidth of many gigabits, while broadband systems are 
more limited. 


Fiber segments 


Fiber is used in many organizations in a similar role to broadband—as 
a backbone cabling system. Fiber is also used as a wide area back- 
bone because of its tremendous potential bandwidth of gigabits per 
second. Because fiber does not oxidize as copper does, it is becoming 
the wide area backbone for many organizations. DEC, for example, 
has an extensive fiber optic network linking their Massachusetts and 
New Hampshire facilities together (see the case study in the next 
chapter for more information). 

Fiber is used in three different scenarios for LAN technologies. Most 
often, fiber is used as a method of connecting bridges or repeaters 
together. The fiber in this case is not used to connect nodes to the 
Ethernet, only to connect separate segments of Ethernets together. 

The second use of fiber is as a backbone environment. In this case, 
fiber actually forms part of an Ethernet segment but has very few 
hosts connected to it. The LattisNet example in the next section is an 
example of using fiber as a backbone network. 

The third option is to actually connect hosts to the fiber. This is 
usually done in an environment with security constraints because it is 
harder to attach to a piece of fiber and remain undetected than it is to 
a ThickWire segment that can accept a vampire tap without interrupt- 
ing service. 


Twisted pair segments 


Ethernet implementations using twisted pair wiring are quite attrac- 
tive because many organizations have excess twisted pair already in 
place for their phone system. In some instances, these wires can be 
cannibalized to provide Ethernet access and eliminating the need to 
lay more cable. 

Twisted pair has several advantages over more traditional Ethernet 
media. First, it can provide a transition to the four-wire ISDN physi- 
cal interface. Second, it is lighter, more flexible, and smaller than 
coax cable. Twisted pair can be used in Ethernet as well as token ring 
networking schemes, allowing the network manager the flexibility to 
change LAN technologies. 
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On the other hand, coax can be used for longer distances because of 
its greater insulation. A limitation of twisted pair is that wires cannot 
be placed directly next to those used for phone systems. This is be- 
cause when a telephone rings, a high volt signal is transmitted down 
the wire. This limits the situations in which unshielded twisted pair 
can be used. 

Most implementations of twisted pair Ethernet still use coax cable 
or fiber as a backbone. The twisted pair wiring is attached onto a 
segment of coax using a device called a BALUN (balanced-unbalanced) 
adapter. This device has an RJ11 or RJ45 connector for the twisted 
pair and a standard BNC connector for the ThinWire. The device con- 
verts the 60- to 90-ohm coax impedance to the 120- to 140-ohm im- 
pedance of the twisted pair. 

The coax segment of the BALUN is then connected to some form of 
concentrator. In the case of DEC, this is usually a single port of the 
DEMPR. A single segment of twisted pair in this configuration can be 
up to 70 m long. At the node end of the connection, the twisted pair is 
once again converted into ThinWire to connect to the DESTA, which in 
turn connects to the Ethernet controller. 

Another vendor that has been prominent in the twisted pair Ether- 
net market is SynOptics Communications. Their LattisNet uses a com- 
bination of fiber and twisted pair. Nodes are connected to con- 
centrators using twisted pair. Fiber is then used to connect con- 
centrators together. A segment of twisted pair is able to go up to 360 
feet (ft) before it has to join a local concentrator. 

Concentrators in LattisNet can be either local or global. A global 
concentrator is the same as a local except that it has the capability to 
have other concentrators connected to it, while the local concentrator 
can only accept connections from hosts. Global concentrators may in 
turn be in a hierarchical configuration (a “super” global concentrator). 

Local concentrators can have three or eight host modules depending 
on the model. A typical host module is the twisted pair module which 
can accept up to eight twisted pair connectors while a fiber module 
can accept up to four fiber optic connections. 

Each local concentrator also includes a power supply module and a 
terminator module. The terminator module uses fiber to connect to a 
global concentrator. The global concentrator includes a retiming 
module which retimes and amplifies signals before transmitting them 
back down the tree. 

The entire LattisNet is considered to be a single segment of Ether- 
net. It is thus possible to use one of the twisted pair ports and con- 
nect that to a BALUN, which is connected to one side of an Ethernet 
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repeater. That repeater in turn would be connected to another Ether- 
net segment, such as a baseband segment. 

The advantage of twisted pair is that many sites already have two 
unused pairs of wire going into each office. For example, many sites 
adopted the AT&T Premises Distribution System (PDS) which 
specifies that each office should have four pairs of wires. Since most 
phone systems only use two pairs for each telephone unit, a LattisNet 
or twisted pair network can plug right in without laying cable. 

It is important to recognize the convenience of not having to lay 
cable. In many organizations, facilities maintenance is an entirely dif- 
ferent group from data communications. Often, this relationship can 
deteriorate if the data communications staff insists on tearing up the 
building when the building staff is busy concentrating on allocating 
parking spaces. If the wire is already there, it means one less depart- 
ment to contend with. Of course, the voice wiring may be “owned” by 
a separate department, but that is another issue! 


Comparison of different media 


A particular set of computers can be wired together using any one of 
the media discussed. Usually, each type of media fits a special pur- 
pose. Broadband and fiber, for example, are usually used as an Ether- 
net backbone. In a campus environment, this media would be used to 
connect multiple buildings together. 

Baseband or ThickWire is also used as a form of backbone. Often, 
this medium is used in the machine room and to connect various floors 
of a building together. It is not uncommon to see broadband used to 
connect buildings together and baseband used to connect floors 
together. ThinWire and twisted pair are usually used as a local dis- 
tribution method. User workstations, such as MicroVAXs, terminal 
servers, PCs, and Macintoshes are often connected to either type of 
media. 

Repeaters are used to connect these different types of media 
together into a single multisegment Ethernet. An alternative to con- 
necting segments with a repeater is to use a bridge or a router. While 
the repeater operates at the physical layer of the network, bridges and 
routers operate at the next two layers. This allows some forms of 
filtering and control over cross-segment traffic, but at the expense of 
performance. In a wide area environment, repeaters are not a viable 
option and bridges and routers are used to form connections. 
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Fig. 6-6 Ethernet repeaters. 
Repeaters: Multisegment Ethernets 


The limits of a single-segment Ethernet may be reached because of 
either distance limitations or because the number of nodes has 
reached the maximum. As previously discussed, a single baseband seg- 
ment can only have 100 transceivers on it and can be only 500 meters 
long, while a single ThinWire segment can only have 30 nodes and be 
185 meters long. 

A repeater retimes and reamplifies the signal on an Ethernet and 
allows multiple segments to be tied together. The basic rule for 
repeaters is that there can be only two repeaters in the path between 
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Fig. 6-7 DEREP Ethernet repeater. 


any two nodes on the Ethernet. This two repeater rule has been ex- 
panded to four repeaters by the IEEE. DEC supports only two- 
repeater configurations to minimize the delay introduced into con- 
figurations with many repeaters. Figure 6-6 shows a basic repeater 
configuration. 

The two repeater rule means that a multisegment Ethernet usually 
consists of a backbone with segments fanning out from it. This might 
mean a backbone down the elevator shaft of a building and then seg- 
ments on each floor. Alternatively, it might mean a backbone between 
buildings and then a single segment per building. 

The basic DEC repeater is the DEREP. A DEREP connects two 
separate baseband segments together. Since the DEREP is connected 
to two segments, it needs two transceivers and two transceiver cables. 
Each transceiver cable can be 50 m long, so the individual segments 
can be as much as 100 m apart. 

A remote repeater consists of two DEREP units. Each one is con- 
nected to a single baseband segment. In between the two DEREP 
units can be as much as 1000 m of fiber optic cable. Between any two 


134 DEC Networks and Architectures 


Fig. 6-8 Multiport repeaters. 


nodes on the Ethernet, there can be only 1000 m of fiber optic cable. 
This could be split between two sets of remote repeaters or can all be 
used on a single remote DEREP. Figure 6-7 shows a photo of a DEC 
DEREP repeater. 

Fiber as a way of connecting Ethernet segments will be seen again 
in the discussion of extended Ethernets later in this chapter. In that 
type of configuration, fiber optic is used to connect seperate Ethernets 
into an extended Ethernet. Repeaters connect multiple segments into 
a single Ethernet. It is important not to confuse the 1000-m repeater 
rule with configuration guidelines for extended Ethernets. 

The maximum separation of two nodes on a baseband Ethernet can 
be calculated as 2800 m: 


a Three 500-m coax segments 
sw Six 50-m transceiver cables 
a One thousand m of fiber 


Local Area Networks 135 


The total amount of cable on this subnetwork could be much greater 
than 2800 m. The rule only serves to limit the total distance between 
any two nodes and not the total amount of cable. 

ThinWire segments are connected together using a multiport 
repeater. DEC’s DEMPR allows up to eight segments of ThinWire to 
be connected together. A single segment of ThinWire can have 30 con- 
nections on it, and the DEMPR counts as 1. This means that up to 8 
times 29, or 232, nodes can be put on a single DEMPR (See Figure 
6-8). 

The DEMPR can function as a stand-alone unit in an exclusively 
ThinWire network. The DEMPR can also connect to a segment of 
baseband. Since the DEMPR is a repeater, it counts against the two- 
repeater limit between any two nodes on the Ethernet. 

The DEMPR is frequently used as a wiring concentrator in a cluster 
of offices. Baseband is used as a backbone between floors, and the 
ThinWire segments are connected to the backbone using a DEMPR. 
Optionally, the DEMPR can be connected to a DELNI, which in turn 
is connected to the backbone. This configuration is often used when a 
single floor has a combination of terminal servers and DEMPR ports 
on it, all connected to the DELNI. 

Both the DELNI and the DEMPR add delay to the Ethernet as they 
must both receive and rebroadcast all signals. If a network consists of 
a baseband backbone, with ThinWire segments connected by a com- 
bination of DEMPR and DELNI, the backbone can only be 300 m long. 


Extended Ethernets 


There are several reasons that the limits of a single Ethernet may be 
reached. The most obvious is that the 1024 node-limit has been 
reached. Another limitation is that because of restrictions on segment 
sizes and the numbers of repeaters, a distance limitation has been 
reached. Thirdly, the number of nodes may be less than 1024, but 
they may be saturating the media. A final reason is administrative— 
finance may not be willing to have accounting in charge of “their” net- 
work. 

Multiple Ethernets can be connected together into an extended 
Ethernet. An extended Ethernet looks like a single piece of cable to 
the Ethernet user—for example a DNA routing layer. All nodes on 
this extended Ethernet appear as though they were connected to a 
single piece of logical cable. Figure 6-9 shows two Ethernets con- 
nected together into an extended Ethernet. 
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Fig. 6-9 Basic bridge configuration. 


A bridge is used to connect the separate Ethernets; this is a device 
connected to two separate Ethernets and belongs to each one. The 
bridge listens to the packets on each Ethernet. If the packet is local to 
the Ethernet it is heard on, the bridge ignores it. If the packet has a 
remote Ethernet address on it, the bridge forwards the packet onto the 
second Ethernet and rebroadcasts it. 

It is important to remember that each of the two Ethernets com- 
bined together could be in themselves a fairly complex topology. The 
rules for an individual Ethernet on distance, node, and repeater limits 
still apply. For simplicity, the diagrams in this book show individual- 
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segment Ethernets connected together using bridges. Each of these 
individual Ethernets could instead be a multiple-segment network. 

Although it is possible to have an infinite number of bridges in an 
extended Ethernet, each bridge adds processing time for filtering and 
forwarding packets. This is crucial in timer-based protocols like LAT, 
which expect to receive an ACK on a packet within 80 milliseconds. 

A bridge adds a little over 1 ms to the longest path delay time on an 
extended LAN. DEC recommends no more than eight bridges in the 
path between any two Ethernets to keep the total path delay under 10 
ms in time-critical applications like LAT or LAVC traffic. 


Automatic learning 


Bridges quickly learn the addresses of all Ethernets that lie to either 
side of them. This allows the bridge to build up a forwarding database 
and increases the forwarding rate and prevents excessive rebroadcast- 
ing of packets. The forwarding database can have up to 8000 entries 
in it, enough for most applications. 

When a packet is sent, the bridge knows that the source address it 
hears lies in that direction. It is possible that the destination address 
is either in that direction or on the other side of the bridge. When the 
bridge encounters an unknown destination, it forwards the packet. 
Eventually, the node that receives the packet will send a reply. That 
reply will have the unknown node as the source. See Figure 6-10 for 
an illustration of this process. 

In this way, the bridge is able to learn about the existence of pre- 
viously unknown nodes and update the forwarding database. 

The question of which packet to forward is a crucial one for the 
bridge. Each node on each Ethernet has an address. When a bridge 
powers up, it begins by listening to each network and builds up a list 
of addresses. This prevents the bridge from sending a packet back out 
on the same Ethernet and flooding the network with duplicate pack- 
ets. 

There is an extremely high probability that a packet sent will 
generate an acknowledgment from the target node or will be followed 
by another packet from the source. A two address cache will thus 
provide the forwarding rule for up to 60 percent of the packets the 
bridge must forward. 
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Fig. 6-10 Bridge learning algorithm. 


Spanning tree algorithm 


An important consideration on an extended Ethernet is that the 
bridges should not form a loop. Suppose a series of four Ethernets. 
Ethernets A and B are connected by a single bridge. Ethernets B and 
C are connected by dual bridges. Ethernets C and D are connected 
with a single bridge. Figure 6-11 illustrates this configuration. 
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Fig. 6-11 Chernobyl effect example. 


Now suppose that a new node is added to Ethernet A. It immedi- 
ately transmits a packet with an address on D. Bridge B2 hears the 
packet broadcast, recognizes the address as not being local, and 
rebroadcasts it out on Ethernet C. Bridge B3 hears this packet on 
Ethernet C and sends it back to Ethernet B. In the case of a broad- 
cast address, this pattern can quickly generate a tremendous amount 
of cyclical traffic out of one packet—known as the “Chernobyl effect” 
by some. 

To prohibit this type of a loop, bridges begin by configuring them- 
selves as a spanning tree. This means there is only one path to a 
particular Ethernet from a given point, as opposed to a more general 
mesh topology. Several vendors, including Digital, Vitalink, and Chip- 
com use the same spanning tree algorithm, allowing different brands 
of bridges to mixed in a single extended Ethernet. 

If there are two bridges connecting a pair of Ethernets, some bridge 
implementations, including DEC’s, allow one of the bridges enters a 
hot backup state. The backup bridge periodically monitors the Ether- 
net to listen for the status message of the active bridge. If it is not 
received after a time-out period, the backup bridge takes over. 
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Multicast addresses and filtering 


Rebroadcasting packets with multicast addresses can have potentially 
disastrous effects on an extended Ethernet. A single broadcast mes- 
sage asking for help (i.e., the location of a nameserver) could generate 
a large number of responses, particularly if the response to the multi- 
cast is another multicast message requiring further assistance. This 
same phenomenon can occur on a single Ethernet, but the number of 
nodes in an extended Ethernet can compound the seriousness of the 
problem. 

Some bridges, such as those made by Vitalink, allow the manager to 
filter out certain types of traffic. Usually, multicast messages are one 
of the first types of traffic filtered out. Another option is to filter out 
whole protocol families. For example, the San Diego Supercomputer 
Center has a series of bridges that link it to the academic network at 
the University of California at San Diego. The bridge is used to filter 
out the protocol families used by students and thus creates a firewall 
around the center. Researchers that use the same protocols as the 
Center have their packets forwarded as normal. 


Types of bridges 


Several types of bridges are available. The LAN Bridge 100 is DEC’s 
basic bridge. It connects via transceiver cables to two separate Ether- 
nets. The two Ethernets can thus be up to 100 m apart. Usually, 
both Ethernets terminate in a common wiring closet and separation of 
the networks is not an issue. 

A remote bridge combines the DEREP repeater with the LAN 
Bridge 100. A DEREP is connected to one Ethernet and the bridge is 
connected to a second one. The bridge and the repeater can be con- 
nected by up to 500 m of fiber optic cable. In addition to the 500 m, 
this configuration can use anything that is left over from the 1000 m 
limit of fiber optic cables connecting repeaters in the network. Thus, 
if no fiber repeaters are used, the bridge-repeater combination can be 
separated by up to 1500 m of fiber. Figure 6-12 illustrates the dif- 
ferent types of bridges. 

Two bridges can also be connected by fiber. If a bridge is located on 
each end of the connection, up to 3000 m of fiber can be used. Since a 
bridge is more expensive than a repeater, this configuration costs 
more than the bridge-repeater configuration. 

Fiber links are used to connect separate buildings together into 
either a multisegment Ethernet or an extended Ethernet, depending 
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Fig. 6-12 Three types of Ethernet bridges. 


on whether bridges or repeaters are used. Unfortunately, it is not 
always easy to secure permission to tear up the corporate parking lot 
to lay the fiber. While computers are a key corporate resource, most 
network managers will soon find that computers are low in priority 
when compared to parking spaces. 

A solution to this situation is the use of a microwave link between 
buildings. The microwave link is combined with a LAN Bridge 100 to 
form DEC’s METROWAVE Bridge solution. This uses microwave 
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equipment made by M/A-Com, Inc. This solution only works if there 
is a line-of-site link between the buildings that is 4.5 miles or less. 

The limiting factor in the extended Ethernet is the ability of the 
bridge to monitor two separate Ethernets and then rebroadcast the 
packet. A high level of traffic destinated for the other Ethernet can 
saturate the bridge buffer space and lead to undelivered traffic. Since 
Ethernet does not assure delivery of data, the transport layer would 
eventually detect that it had not received a segment and ask for 
retransmission. The retransmission can lead to an increase in the 
amount of traffic on an already saturated bridge. 

Buffer overflows are not usually a problem for local and fiber 
bridges. These devices are often able to filter packets and forward 
them as fast as any incoming traffic. The LAN Bridge 100, for ex- 
ample, can filter packets at a rate of 24,200 packets per second, and 
can forward packets at rates of 13,000 packets per second. Wide area 
bridges, discussed in the next chapter, have significantly lower packet- 
forwarding rates because of the lower bandwidth of the connections 
involved. 

Bridges tend to be used in two kinds of situations. One is to isolate 
a work group, often consisting of diskless nodes that do all I/O opera- 
tions over the Ethernet. The other is to connect two separately ad- 
ministered, often very large, networks together. Often the networks 
are connected together using bridges that support a common carrier 
link over fairly long distances. 

Often, it is not really necessary to have a bridge between two Ether- 
nets. If the amount of traffic is relatively small or occurs only in off- 
peak hours, a router connected to two different Ethernets is a possible 
solution. This router can be a MicroVAX or VAX configured as a DNA 
routing node. 


Servers 


In the arcane study of economics, there is an even more arcane prin- 
ciple that states that global optimization within a single system will 
not produce a locally optimal solution for any part of that system. 
This principle can be easily applied to computers. A single VAX can- 
not be optimized for multiple types of applications. This is because a 
single application has a set of operating characteristics, such as the 
dynamic nature of memory requirements or the pattern of user input. 
A VAX, especially with the VMS operating system, has a great num- 
ber of parameters that allow the system to be tuned to a particular set 
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of operating characteristics. Tuning for any one application will thus 
not be optimal for other applications. 

The solution to the problem of global optimization is to distribute 
processing on special-purpose computers. An obvious example is the 
problem of terminal users. When terminals are connected directly to a 
VAX, a great deal of VAX CPU cycles are spent echoing characters 
onto user screens, polling for user input, and other maintenance tasks. 
This means that the VAX CPU cycles are unavailable for the intended 
purpose, such as inverting matrices or making hyphenation decisions. 

DECnet and other architectures such as LAT provide a layer of 
transparency allowing multiple computers to cooperate to produce ser- 
vices for users. Servers are dedicated computers that participate in 
these networking protocols and are optimized for a particular task. 
This doesn’t mean that the hardware manufacturer had to modify cir- 
cuit boards for particular functions. A general-purpose computer, such 
as a MicroVAX II, can easily be tuned for specific types of functions 
and become a dedicated server. 


Terminal servers 


Terminal servers use the LAT architecture that was previously dis- 
cussed in Chapter 4. The LAT architecture is a set of protocols that 
are optimized for transmitting many relatively short packets over an 
Ethernet. Because all nodes are on the Ethernet, there is no need for 
a routing layer. Transport and session functions are all folded into 
the general-purpose LAT architecture. 

Terminal servers are devices that implement the LAT architecture. 
It should be noted that LAT is not the only way to provide this service 
over the network—other terminal servers have been designed to use 
TCP/IP or XNS protocols. LAT just happens to have been developed 
by DEC, so DEC terminal servers use it. 

The DECserver 200 is a low-cost terminal server with eight ports. 
A special version of the DECserver 200 has modem control, allowing 
the terminal server to terminate a session when the user hangs up the 
phone from a remote site. Without modem control, the session stays 
in place, including a virtual circuit to a host. The next user that is 
connected to that modem port is automatically passed through to an 
existing session on a host without having to log in. Needless to say, 
this is not optimal from a security standpoint. 

The DECserver 500 is a server that can be configured with up to 
128 ports. The server can have up to eight interface cards. A CXY08 
interface card has eight RS-232-C ports on it. If all eight of the slots 
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Courtesy of Digital Equipment Corporation 


Fig 6-13 DECserver 500 with two slots open. 


Courtesy of Digital Equipment Corporation 
Fig. 6-14 Assembled DECserver 500. 
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Fig. 6-15 Different devices on a terminal server. 


on the server are filled with CXY08 cards, the server can accom- 
modate 64 ports. Figures 6-13 and 6-14 show a DECserver 500 with 
different line cards. 

A second interface card is the CXA16. This consists of 16 DEC423 
ports per card. If all cards on the DECserver are CXAl16s, the server 
has 128 ports on it. A third interface card is the CXB16 which con- 
sists of 16 RS-422-A ports. All three types of interface cards can be 
mixed on the same server. 

Each port on the terminal server is in one of four modes. First, the 
port can be disabled. Second, it can be in local mode, meaning that 
the initiating user of a session will be a locally connected terminal (or 
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a modem). The third connection option is remote, meaning that the 
user will come from a LAT host. An example of this is attaching a 
printer to the port in which case the remote user will be a special 
print symbiont. 

The last port configuration option is dynamic and is able to flip be- 
tween local and remote modes. This option is used when a modem is 
attached to the terminal server. The modem is able to accept either 
incoming or outgoing calls. Incoming calls are local mode—the session 
is initiated from the port side of the server. Outgoing calls are 
remote—the session initiated from the Ethernet side of the server. 
Figure 6-15 shows the different uses of a terminal server. 

When a printer is used on the terminal server, there must be a host 
configured to use this printer. Users queue jobs to this supporting 
host, which then uses a special print symbiont to transfer data using 
the LAT protocols. This is different from the LPS40 which uses the 
DNA protocols to transmit print data. 

The server print port is able to accept print requests from multiple 
hosts. Only one connection can be active simultaneously. Incoming 
connect requests from hosts are queued at the server. 

When users connect to the terminal server, they are usually un- 
aware of the concept of ports. Instead, they look for services they wish 
to connect to. When they log onto a terminal server, they are given a 
list of all services they are authorized to know about. It is possible 
that the LAT server can make the connection to the service but that 
the user does not have an account on that system and is refused ac- 
cess. 

Services are usually VAX systems. If the service is a VAX Cluster, 
the user is logged onto the cluster node that has the best service 
rating. It is also possible to have nonclustered nodes all offering the 
same service. An example is configuring several small MicroVAX sys- 
tems as dial-out service providers. 

In order to offer a service, the host must provide LAT support. Be- 
cause of that, terminal server users are unable to connect directly to a 
DECnet X.25 Gateway, a DECnet Router, or a DECnet SNA Gateway. 
That is because these nodes all speak DNA and not LAT. The services 
of an intermediary host that speaks both languages must be employed. 

Other services may be offered by the terminal server itself. These 
services are advertised just like host-based services and become part 
of the directory listing on each terminal server. A host may consist of 
a single port, or a group of ports all offering the same service and 
configured as a rotary. 

Another use of remote mode is to allow the VMS host to get access 
to external resources. One example of this is dial-out access. A 
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Fig. 6-16 Using terminal servers for foreign hosts. 


second use is to configure the ports for reverse LAT capability. Ifa 
host is on the network but does not support DNA (or some other com- 
mon Ethernet protocol such as TCP/IP or XNS), the VAX and the 


foreign host do not share a common language. 
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Most hosts are able to accept asynchronous terminal access. 
Reverse LAT capabilities mean that the asynchronous ports on the 
foreign host are all connected to terminal server ports. The LAT host 
is then able to set up a connection to that terminal server port, which 
is then passed through to the host as though it were a local connec- 
tion. Figure 6-16 illustrates this configuration. 

The use of terminal server ports to connect to hosts is a common 
way to integrate dissimilar networking environments. If one terminal 
server speaks one language (say TCP/IP) and another server speaks 
LAT, the Ethernet consists of two dissimilar environments. The LAT 
hosts can speak to the LAT servers, and the TCP hosts can speak to 
the TCP servers. 

By connecting an RS-232 cable between a port on each server, there 
is at least the ability to log into a remote system. From there, file 
transfer protocols such as Kermit can be used to pass data back and 
forth. While this provides a minimum level of connectivity, it of 
course does not provide the full bien of network-based file 
transfer protocols. 

A special instance of the terminal server is the MUXserver 100. 
This device is designed to support remote access to terminal servers. 
The MUXserver is a combination of the DECserver 100 and the DFM 
Series multiplexers. The remote user configures a DECMUX II with 
up to eight lines and then uses a leased line or a null modem to con- 
nect to the MUXserver. 

If the MUXserver is not optimal, because of the 16 port limitation, 
for example, it is quite simple to configure a similar system. Users 
can configure a rotary of ports on a DECserver 500 for incoming calls. 
A multiplexer, made by DEC or by another vendor, is then connected 
to each of those ports and to a modem. The modem connects to a peer 
modem over a leased or dial-up line and the remote modem is in turn 
connected to another multiplexer. 


Print servers 


Print services in a LAN environment are usually accomplished in 
three different ways. First, individual workstations or hosts may have 
printers attached to them. Each individual node is responsible for 
managing the queue on its own printer. With the Distributed Queu- 
ing Service discussed in Chapter 2, it is possible to integrate all these 
separate queues into a common printing environment. 

The other two methods of providing printing services are through 
dedicated print servers and by attaching printers to a terminal server. 


Local Area Networks 149 


Attaching a printer to a terminal server was discussed previously and 
uses the remote port configuration option of the terminal server. 

A dedicated print server attaches to the Ethernet, just as a terminal 
server or a host does. The server thus off-loads much of the print 
management tasks from host computers and allows an expensive high- 
speed laser printer to be shared among many users. DEC’s LPS40 is 
a 40-page-per-minute laser printer. The LPS40 includes an Ethernet 
controller and DNA software. Like other servers, it requires a Phase 
IV host for downloading the initial software. The MOP protocols are 
used for the initial downline load operation. 

The supporting host has a copy of the VAX PrintServer 40 Support- 
ing Host Software. There can be only one host active for each laser 
printer, although a single host can manage multiple LPS printers. 
The Supporting Host Software consists of two pieces. The 
downloadable image is used to initialize the printer. The second 
software component is management software. The management 
software is used to activate and deactivate functions such as new job 
acceptance by the printer, to abort jobs, and to control event logging. 
Event logging includes the numbers of copies printed by job. 

A variety of status commands is also provided by the management 
function. Unprivileged users can query the print server status and 
characteristics. They can also, see which jobs are currently queued 
and the characteristics of currently active jobs. 

Hosts that wish to use the services of the LPS40 each need to have 
installed PrintServer 40 Client Software. This includes a print sym- 
biont which is able to accept requests from multiple queues. The 
client software also includes software that can establish a DNA con- 
nection to the printer. 

A single LPS40 is able to accept requests from up to 16 clients. 
Only one connection is active at any one time, the others being queued 
up. It is also possible for a single instance of the client software to 
dispatch requests to multiple print servers. 

The LPS40 is only able to accept PostScript input. The client 
software includes three translators that allow incoming data streams 
to be in non-PostScript format. ANSI text, ReGIS graphics, and 
Tektronix 4010/4014 data streams can all be translated into Post- 
Script. By allowing the client software to perform the translation, the 
applications software, such as a word processing program, does not 
have to be reinstalled. 

The symbiont which is part of the client software has several 
parameters available that are peculiar to the LPS environment. First, 
because this is Ethernet based, the print symbiont supplements the 
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normal accounting information of the number of sheets per job with an 
indicator of the number of QIO writes over the network per job. 

The symbiont is also able to accept parameters that specify the loca- 
tion of a PostScript initialization file. These PostScript preambles are 
used by many software environments to customize the PostScript en- 
vironment for their particular needs. 

Ethernet-based output servers are becoming increasingly common. 
Versatec, for example, manufacturers a TCP/IP based Ethernet plot 
server. Another TCP/IP based print server is the ImageServer XP 
series from Imagen. These are 20 page per minute laser printers with 
5 Mbytes of RAM and a 20-Mbyte hard disk. They use an Excelan 
TCP/IP Ethernet interface but are also able to accept other connection 
methods such as RS-282. 


Communications servers 


Communications servers provide a link to a wide area environment. 
Examples of communications servers are DNA routers that extend 
DNA communications from the Ethernet into a wide area environ- 
ment. This link could be a simple DDCMP link between two VAXs or 
a more sophisticated network. 

This topic is considered more fully in the next chapter on wide area 
networks. 


Compute servers 


It’s important not to forget the most general type of server, the 
general-purpose computer! Distributed processing environments, as 
we have seen, consist of a series of increasingly specialized servers. 
Terminal servers and print servers are two examples. It is also pos- 
sible to take a general-purpose computer, such as a VAX or a Sun 
Workstation, and turn it into a dedicated database server or graphics 
server or modeling server or any other compute-intensive activity. 

General-purpose compute servers can be as simple as a diskless 
MicroVAX that is used to perform some compute-intensive task. Or it 
can be a fully configured VAX Cluster with memory, CPUs, and disk 
resources all offered in a balanced configuration. 

An example of the compute server concept is the database manage- 
ment software sold by SyBase. Many of the developers of SyBase also 
developed the Britton Lee database machine, the IDM 500. The IDM 
500 was a special-purpose piece of hardware that was optimized for 
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relational operations. SyBase, by contrast, takes a general-purpose 
computer and dedicates it to database functions, achieving very high 
rates of transactions processing. This database server can be as small 
as a MicroVAX or Sun Workstation or as powerful as a large scale 
Pyramid or VAX processor. 

High-speed, well-integrated networks allow many computers to be 
distributed throughout the network and dedicated to specific tasks. 
By dedicating a computer to a specific task, it is possible to optimize 
the operating system for that task. Operating systems like VMS are 
capable of being tuned to the specific characteristics of a particular 
program. Since different programs have different characteristics, 
dedicating resources allows more careful tuning of the operating sys- 
tem. The network then allows users to treat all these different resour- 
ces as a single logical computing environment. 


Integration of Personal Workstations 


A terminal can be thought of as a personal workstation, but only in a 
_ very limited sense. Even if the workstation is a PC emulating a ter- 
minal, the device is not able to fully participate in the network. This 
means, for example, that it requires extra steps to transfer a file from 
a VAX to a PC hard disk. Usually, this requires establishing a ter- 
minal session, followed by invoking a file transfer program such as 
Kermit or Xmodem on each of the two nodes involved. 

A PC can alternatively participate fully in a DECnet as a Phase IV 
end node. This means that the copy operation can be as simple as 
typing COPY. The PC on an Ethernet is also able to take advantage of 
the 10-mbps bandwidth instead of the 19.2-kbps typical maximum for 
a terminal or terminal emulator. 

More sophisticated workstations, such as a VAXstation or Sun 
Workstation, can also be integrated into the network. The multitask- 
ing nature of these workstations means that multiple network opera- 
tions can proceed concurrently. This does not necessarily mean that 
the user is functioning in “whirling dervish mode.” One task might be 
a user-initiated remote log-in to another node on the network. 
Another simultaneous network task would be receiving electronic 
mail. In this case, the network is automatically used by the worksta- 
tion. In contrast, the PC user must have mail received on a VAX 
because of the single-tasking nature of the MS-DOS operating system. 
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IBM PC integration 


There are four general ways that two foreign devices such as a DEC 
VAX and an IBM-compatible PC can be integrated together. First, the 
PC and the VAX can participate in the same networking environment. 
An example of this is to have the PC run DECnet-DOS and the VAX 
run DECnet-VMS. Integration is fairly simple because the two nodes 
confirm to the same architectures. 

A second way is to have the VAX participate in the PC-based net- 
working scheme. An example of this is connecting a VAX to a PC 
network such as Novell Net using a token ring or Ethernet adapter. 
The VAX then provides print services, file services, and other facilities 
to the Novell Net participants. The equivalent services would be 
provided in the DNA environment using VMS Services for DOS. 

A third way is to not use the network but instead to use an 
asynchronous connection and emulate a terminal. It is possible for a 
PC to be connected to an IBM token ring and to also have a serial port 
or modem to connect to a VAX. Most PC/XT or PC/AT systems are not 
able to simultaneously keep a terminal emulator and networking 
software active at the same time. Often, the user must reboot the 
system to switch services. 

A fourth solution, if it existed, would be to gateway the two net- 
working environments together. This is possible for DNA and SNA 
and other combinations such as DNA and TCP/IP. This method is not 
available between the PC-based networking environments such as 
IBM Token Ring, Novell, and 3COM, and the DNA environment. 

PC integration into the DNA environment can be accomplished 
using either DEC’s DECnet-DOS software or Technology Concepts’ 
CommUnity-DOS. DECnet-DOS uses DEC Ethernet controllers and a 
few others on a supported equipment list. CommmUnity-DOS uses 
the EXOS 205 adapter from Excelan. 


DEC DOS solutions 


DECnet-DOS is part of the DEC’s Personal Computing Systems Ar- 
chitecture (PCSA). This consists of DECnet as well as menu and com- 
mand-driven user interfaces to access the network. Two data access 
programs, NFT and FAL, are also available as applications in an MS 
Windows environment. 

VAX systems are able to offer virtual disk services for the DECnet 
nodes using a software package called VMS Services for MS-DOS. 
The VAX can also offer CTERM- and DAP-based services to the PC. A 
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more detailed discussion of the DECnet-DOS implementation is con- 
tained in Chapter 8. 

In addition to DECnet, the PC software from DEC includes a VT200 
emulator for use in wide area scenarios and a LAT virtual terminal 
service. The LAT service allows users to have terminal service fea- 
tures such as load balancing and directory listings. 

Polygon and several other vendors also offer LAT terminal 
emulators for PC systems. Polygon allows the LAT terminal emulator 
to be Ethernet based. It is also possible to connect PCs to a VAX 
simply as a terminal emulator, either on a terminal server or on a 
VAX asynchronous communications port. 


CommUnity-DOS 


CommUnity-DOS provides the basic Phase IV end node functions. 
This includes the virtual terminal capability, file transfer, task to task 
communications, and local management. Like other versions of DOS- 
based DNA, this does not let the PC offer files to other users. Only 
client-based DAP services are supported. 

Built on top of the task-to-task interface on CommUnity-DOS is a 
virtual disk utility. The virtual disk utility allows user to store files 
on an F: directory on their PC. The BIOS calls for the F: disk are 
intercepted and turned into network-based data access instead. 


Apple Macintosh integration 


Apple Macintosh systems can participate in three different networking 
environments. Macintosh systems can be DNA end nodes using 
DECnet implementations from Technology Concepts or from Alisa Sys- 
tems. Apple systems can also participate in a TCP/IP environment. 
Finally, the Macintosh can be part of an AppleTalk environment. Of 
course, there are many other options available such as the TOPS net- 
work from Sun or TCP/IP. 

An AppleTalk network consists of a 230 kbps network to which com- 
puters and printers are connected. This AppleTalk network can be 
connected to a TCP/IP Ethernet using the FastPath bridge from 
Kinetics. Macintoshes can also be directly connected to the TCP/IP 
Ethernet using an Excelan EtherPort controller. 

Once the connection to the Ethernet is made, a VAX can provide 
services using AlisaTalk software for VMS. This software provides a 
virtual AppleBus (a single segment of an AppleTalk network) which 
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runs under VMS. The VAX is able to offer file services, print spoolers, 
and virtual terminal access to the rest of the DECnet. Several other 
vendors offer similar packages. 

Terminal emulation can be provided over a variety of connection 
methods using the MAC240 package from White Pine Software. This 
includes a utility which can convert MacDraw and MacPaint images 
into the DEC-compatible ReGIS and SIXEL formats. ReGis is object- 
oriented and is used for drawings, while SIXEL is a bit-map oriented 
format used for paintings. Again, several other vendors offer similar 
packages. 

A variety of applications development tools are able to use the ser- 
vices of the VAX to provide a Macintosh oriented user interface. An 
example of this is CL/1, which was developed by Network Innovations, 
an Apple subsidiary. This software is an applications development 
language that allows Macintosh applications developers to access a 
variety of different data stores such as commercial database systems 
or RMS files on a VAX. 


Network terminals 


Although a VAXstation can operate as a multitasking set of protocols, 
the network services examined in DNA are oriented around a single 
user on each end. There is no provision for multiple processes to all 
share a bit-mapped graphics screen. Instead, a single window is 
opened for each terminal session on the network. 

The last part of this book discusses the X Windows protocols that 
allow multiple applications to share the real estate on a bit-mapped 
graphics screen. This means that a new window can be opened by the 
application and that applications can communicate with each other. A 
database server, for example, might be programmed to send data to a 
word processing program, which then opens a window to display a 
formatted document. 

With the X Windows System, and an underlying transport 
mechanism such as DECnet, it is not necessary for each user to have a 
personal workstation. The workstation is a general-purpose computer 
that happens to be used as the user interface. Instead, a special-pur- 
pose piece of equipment, known as a network terminal, can be put on 
the users’ desks and all computing resources are distributed 
throughout the network. This network terminal has DECnet (or OSI 
or TCP/IP) and the X Windows protocols and relies on the network for 
other resources. 
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The advantage of the network terminal is very simple. A dedicated 
piece of hardware like this can be made more cheaply than a general 
purpose computer system such as a VAX. Since DEC, Sun, and many 
other vendors have endorsed a common set of protocols including the 
X Windows System and OSI, the network terminal can be used in any 
of these computing environments. 

There are several vendors that are beginning to specialize in X-com- 
patible terminals. There is some question as to whether these ter- 
minals will be able to displace more general-purpose workstations, 
such as a VAXstation, Sun Workstation, or IBM PS/2 system. 


Facilities wiring: DECconnect 


The planning of facilities wiring is a crucial aspect of a network’s 
ability to grow in a steady, modular fashion. Poor planning can lead 
to long delays because of the necessity of tearing up a building to lay 
new cables. 

Several strategies are available, including some formalized ones 
such as AT&T’s Premise Distribution System, IBM’s Cabling System, 
and DEC’s DECconnect. All of these strategies provide a method of 
wiring a facility at one time and then adding nodes to a network 
without extensive rewiring. 

No single methodology is able to meet every situation. It is impor- 
tant to examine a particular facility and mold the wiring strategy to 
meet the special needs of that environment. A well-planned wiring 
plan allows for cost-effective wiring and for modular growth of nodes 
on the network. 

Most wiring strategies consist of a mix of different physical media. 
Some media, such as ThinWire, is cheap and flexible. However, Thin- 
Wire is only recommended for horizontal distribution and not as a 
backbone in places like elevator shafts. In those places, ThickWire or 
broadband might be more appropriate. 

DECconnect is DEC’s recommended way to wire buildings for Ether- 
net-based networks. Like the IBM Cabling System, this is simply one 
company’s view of the proper way to distribute cables in large build- 
ings. Several alternatives strategies are available and may be better 
suited to particular applications. 

DECconnect uses a series of satellite equipment rooms (SER) as dis- 
tribution points to individual offices. The SERs and the main comput- 
ing area are all connected together with a baseband Ethernet back- 
bone. Also terminating in the SER are video and voice facilities. 
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Fig. 6-17 A DECconnect satellite equipment room. 


A series of four cables is strung from each office to the SER. Two 
twisted pair connects are strung, which can be used for terminals, 
phones, or unshielded twisted pair Ethernet connections. A CATV 
cable is strung for video and a ThinWire coax cable is strung for 
workstations and other Ethernet nodes. 

Each office then has a faceplate which can accommodate up to four 
connections consisting of video, voice, terminals, and workstations. 
The ThinWire port is really the end point of a ThinWire segment. 
Several ThinWire nodes could be connected to this faceplate, as long 
as parameters such as maximum cable length, node separation, and 
number of nodes are not violated. Figure 6-17 and 6-18 show a SER 
and the standard faceplate. 

The SER itself consists of two racks. One rack holds equipment. 
Typically, this is one DELNI that connects to the backbone cable that 
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Courtesy of Digital Equipment Corporation 


Fig. 6-18 DECConnect face plate. 


passes through the SER. The DELNI is then connected to a series of 
terminal servers and multiport repeaters (DEMPR). 

The equipment rack thus serves as a distribution point from the 
Ethernet backbone. Next to the equipment rack is a patching rack. 
On the right side of the patching rack is where all the wiring to the 
offices terminates. On the left side are all the wires leading to the 
terminal servers and multiport repeaters. 

When a user moves into an office, a patch is put in place to connect 
the users’ equipment to a port of the equipment rack. Since all the 
wiring is done in advance, it becomes easy to connect new users. 

The number of users a single SER can support depends greatly on 
the users’ proximity to the SER. The typical SER can support 48 to 
64 faceplate connections. Up to 80 connections can be patched in and 
active at any one time. Needless to say, these DEC-furnished 
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guidelines do not illustrate any physical limitations but are simply 
advisory. 

The DECconnect system is one of several strategies that can be pur- 
sued. As can be seen, DECconnect places heavy reliance on the use of 
DEMPR and ThinWire coax cable, and it is appropriate for most office 
environments. Other organizations, such as a manufacturing environ- 
ment with a lot of electrical noise, may wish to base their network 
strictly on ThickWire. This is because ThickWire, with its larger 
shielding, is more resistant to outside noise. Fiber or broadband is 
another possibility for this type of environment. 

It should be noted that electrical noise, known as electromagnetic 
interference (EMI) is rarely a serious problem in most environments. 
EMI is measured in volts per meter (v/m). ThinWire Ethernet is able 
to function in environments with EMI ratings as high as 1 v/m. 
Broadband and ThickWire are able to withstand 5 v/m. A DEC field 
survey of a variety of industrial networking sites found that even the 
most exceptional sources of EMI, such as a printing press or other 
heavy industrial equipment, rarely produced more than 0.013 v/m. 

An alternative to placing terminal servers in satellite equipment 
rooms is to use another form of front-end network as a switching 
device. The terminal servers are stored in the machine room, and a 
data PBX is used to switch terminals in an office to a port on the PBX. 


Other Media Access Control Options 


DEC, one of the pioneers of Ethernet, has chosen to emphasize that 
type of LAN to the exclusion of others. Token ring and token bus 
systems are alternatives to Ethernet. DEC has endorsed the token 
bus for use in MAP networks and the token ring for use in FDDI 
backbones. 

Ethernet serves as a good general purpose LAN protocol but has 
some limitations for real-time applications. As the number of nodes 
increases, so does the probability of a collision. There is also an in- 
crease in the amount of noise introduced onto the medium by each 
Ethernet adapter. Despite these problems, the CSMA/CD protocols 
scale well with the number of nodes on the network. It is not unusual 
to find an Ethernet with 60 hosts and only 4 percent utilization. 

Because of collision detection, CSMA/CD protocols don’t scale well 
with distance, transmission rate, and minimum packet size. All three 
factors contribute to the amount of time that a packet is active on the 
Ethernet. If the packet does not reside on the network for a minimum 
time, a node might not detect a collision with a packet it sent. 
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An alternative technology to Ethernet is the token bus. A token bus 
is used for MAP networks using broadband physical media. The token 
bus scales well with distance. However, as the number of nodes in- 
creases, so does the amount of time spent passing the token around. 
This limits the number of nodes in a token bus. 

The last data link protocol used is a token ring. In an IEEE 802.5 
token ring, a node does not release its token until the previous data it 
has sent has gone all the away around the ring. This limits the dis- 
tance that a token ring can have. 


IEEE 802.5 token ring 


The token ring standard uses twisted pair wires, like those used in a 
telephone system, as a physical medium. These networks operate at 
speeds of 1, 4, or 16 mbps. 

Each node on a ring has two neighbors to which it is connected. 
When the ring is initialized, a token is passed around. Each node that 
receives a token copies the data to its neighbor on the other side. All 
data is thus received at one node, copied and sent along to the next 
node. 

If a node has data to send on the ring, it waits until it receives the 
token. It then fails to send the token back out, thus claiming it. This 
node can then send a data frame. The frame is copied around the 
ring. The destination address for that frame makes a copy for itself 
and then sends it back out into the ring. The sending node receives 
the frame back, checks it for errors, and then sends the token back out 
into the ring. 

Most implementations of the token ring protocols are centered 
around IBM PCs and compatibles. Novell and 3Com, for example, 
both offer PC-based token ring networking products. As of the writ- 
ing of this manuscript, DEC had not announced any support for IEEE 
802.5 token ring networks as a data link layer of DECnet. 

Incorporation of token ring as a data link layer of DECnet would 
allow a large homogeneous network. This would be useful because in 
many corporations individual departments make individual purchas- 
ing decisions on departmental networks. Later, there is an attempt to 
integrate these disparate systems into a single coherent network. 

There are several alternatives that provide different levels of con- 
nectivity. An inelegant solution is to connect PCs to both a token ring 
and an Ethernet. A computer such as a PC/AT would have to reboot 
when choosing between the two environments and only one environ- 
ment could be active at a time. 
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Another solution is to connect a VAX to both a token ring and a 
DECnet/Ethernet. The VAX would have a token ring adapter and pro- 
vide virtual disk and file services to the PC network. That VAX could 
also serve as a gateway to the larger DECnet environment. Both 
3Com and Novell provide these types of solutions. 


FDDI token ring 


The Fiber Distributed Data Interface is a standard developed by the 
ANSI committee. FDDI uses the same token passing concepts that 
the IEEE 802.5 standard does. However, FDDI operates at a speed of 
100 mbps and has several other characteristics that make it suitable 
as a high-bandwidth data backbone. 

The first difference between FDDI and the IEEE token ring is that 
FDDI sends the token out immediately after transmitting the frame. 
This allows the medium to be used to capacity instead of requiring the 
original data to circle the ring completely before sending the token out 
again. 

A second major difference between FDDI and the IEEE token ring is 
the FDDI capacity management scheme. An FDDI frame has a maxi- 
mum size of 4500 bytes. FDDI allows single frames (asynchronous 
mode) or a series of frames (synchronous mode) to be transmitted. 

The nodes on an FDDI network agree on a target token rotation 
time (TTRT). This number is the amount of time, on average, that 
should pass before a node on the network sees a token again. Note 
that although the TTRT is a measure of expected delay, it also serves 
as a measure of the number of bits that can be transmitted during 
that delay and thus serves as a measure of capacity. The TTRT thus 
serves as a limit on how much data any one node may transmit at one 
time. 

Setting the TTRT is usually done when the network intializes. Each 
node transmits a continuous stream of CLAIM frames that contains its 
target TTRT. If a node notices that the neighbor it receives tokens 
from has a lower claimed TTRT, it defers to that neighbor. Eventual- 
ly, every node will defer to the one with the lowest TTRT. 

To begin with, all the capacity on an FDDI network is allocated to 
asynchronous mode. If a node wishes to transmit synchronous data 
(multiple frames to a single destination), it requests a synchronous 
allotment using a Station Management Protocol. The sum of these 
synchronous allotments must be less than the TTRT. 

When a node receives the token, it may transmit synchronously for 
the time of its synchronous allotment. It may then transmit 
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Fig. 6-19 Dual cable FDDI token ring operation. 


asynchronously so long as the next node still sees a token within the 
TTRT period. 

Asynchronous data is put into eight different priority levels. Data of 
each priority has a parameter for the amount of data that can be sent. 
Typically, small amounts of high-priority data might be sent followed 
by larger amounts of lower-priority data for user applications. Finally, 
the timer would expire and the node would have to give up the token. 

To establish a high-bandwidth dialog with a partner, there is a spe- 
cial form of token called the restricted token. Only the partner of a 
particular node can grab the restricted token, thus allowing request- 
response traffic on the network. The asynchronous bandwidth of the 
capacity can be used for restricted transfer. 

At the physical layer, FDDI is based on optical fiber. A single piece 
of fiber can be used to form a ring between all nodes on the FDDI 
network. A second piece of cable can be used for increased reliability 
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on selected nodes. Class B stations are connected only to the primary 
cable, whereas class A stations are connected to both. 

Because of the high capacity and low attenuation of fiber, the total 
path of the fiber ring can be 200 kilometers (km). The distance be- 
tween any two nodes can be 2 km without the use of repeaters. Up to 
1000 nodes can participate in an FDDI ring. 

Several mechanisms are used to provide a high degree of reliability. 
First, the dual cables provide a degree of reliability (assuming, of 
course, that you put your cables on different paths). Normally, all 
traffic goes on the primary cable. If the there is a break in the ring, 
the node closest to the break will loop data back in the other direction 
on the second cable. 

The second cable is used to bypass the break in the ring and deliver 
the data to the node that would have been receiving the token next. 
That node processes all data and then sends data back out in the 
original direction. Figure 6-19 illustrates this process. 

Breaks in the ring are detected using a BEACON message. BEACON 
messages are sent when no data is received for a long period of time, 
or if a claim arbitration fails to resolve itself. BEACON messages are 
always copied by receiving nodes immediately, even if they were con- 
tinuously sending CLAIM messages. A node can expect to see a 
BEACON message back fairly quickly. If it doesn’t see the message at 
the other side of the ring, it assumes that the cable is broken. 

A second reliability device is the use of wiring concentrators. A 
wiring concentrator is somewhat like a multiport transceiver on an 
Ethernet. One or several devices can be connected to the con- 
centrator. Usually, the devices are Class B devices, whereas the con- 
centrator can be a Class A device. 

Finally, bad stations on an FDDI ring can be circumvented by using 
an optical bypass switch. This means that a station that is powered 
off or malfunctioning doesn’t bring the whole network down by causing 
a break in the ring. 

FDDI has been endorsed by several vendors, including DEC, for use 
as a backbone network. Most nodes would be connected to an Ether- 
net system, in the DEC scheme of things. Routers or bridges would 
then be used to connect FDDI and Ethernet-based systems. Of course, 
there is no reason why FDDI can’t also serve as a backbone for SNA 
and token ring networks as well as Ethernets. 
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Token Bus: Hyperchannel and MAP 


A token bus is usually implemented on a broadband physical medium. 
Instead of a ring technology, the token and data are broadcast on a 
broadband cable, much like Ethernet packets are broadcast on a 
broadband cable. In contrast to the random access nature of the 
Ethernet, however, the token bus technology allows a node to transmit 
only when in possession of the token. 

Hyperchannel is a 50 to 80-mbps token bus implementation used in 
environments with high-bandwidth data transfer requirements. 
Often, Cray supercomputers are connected to a Hyperchannel network 
along with series of VAXs that serve as front-end processors for the 
Cray. The case study of the San Diego Supercomputer Center in the 
next chapter illustrates such an application. 

A second application of token bus technology is in manufacturing 
environments that use the MAP protocol suite to direct the activities 
of robots and intelligent programmable controllers. The MAP protocol 
suite is discussed in more detail in Chapter 12 on the OSI upper-layer 
services. 


Summary 


This chapter discussed a variety of different methods of configuring 
Ethernet networks, ranging from single segment to multisegment to 
extended Ethernets. All of these different configurations appear to the 
routing layer or other data link service user as a single logical bus. 
The next chapter discusses technologies that serve the same purpose 
in a wide-area environment: ISDN and X.25. 

Ethernets allow multiple devices to be connected to a single system 
at high speeds. Because of this functionality, as well as the upper- 
layer users of the Ethernet, it is possible to distribute processing 
among multiple computers. Terminal, database, communications, and 
compute servers all participate in the network. This approach permits 
specialized computers to be added to the network in a modular fashion 
without necessarily affecting the view of the network that the user 
sees. In fact, with the LAT protocols, the users don’t see computers— 
they see services. 
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Chapter 


Wide Area Networks 


Overview of Wide Area Networks 


This chapter begins with a discussion of how to connect remote devices 
together using a dedicated point-to-point link. In the DEC environ- 
ment, this link usually uses the DDCMP protocols. The link might be 
a remote terminal connected to a computer, two computers connected 
together, or two LANs connected together. 

An alternative to using DDCMP for a point-to-point link is to use an 
extended Ethernet. The extended Ethernet uses the same bridge tech- 
nology examined in the previous chapter, but it is extended to a wide 
area environment. The extended Ethernet, because it is protocol- 
transparent, can be used to carry non-DNA traffic such as LAT, 
TCP/IP, or any other user of the Ethernet. 

The Ethernet is an example of a technology that makes every node 
appear to be a single hop away from the users of the Ethernet, such as 
the DNA routing layer. Another form of subnet is X.25. Internally, 
X.25 can be a complex topology, but the X.25 protocols mask this in- 
ternal structure from the user of the subnet. 

A third form of subnet is the Integrated Services Digital Network. 
ISDN is protocol independent to the extent of being able to carry voice, 
video, data, or any other form of information. Like X.25, the ISDN 
permits a virtual point-to-point link to be formed between two proces- 
sors. Unlike X.25, ISDN is able to provide both circuit-switched and 
packet-switched bandwidth and greatly increased control over com- 
munications. 
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Point-to-Point Connections 


Point-to-point connections can be as simple as two VAX systems con- 
nected with DDCMP lines or a terminal talking to a remote computer 
using a 300 bps modem. More sophisticated point-to-point connections 
are used to connect Ethernets together, using dedicated routers or ex- 
tended Ethernets. 

Original implementations of DECnets consisted exclusively of point- 
to-point connections. These point-to-point connections were used even 
in a local area networking environment. Increasingly, point-to-point 
connections are used as a method of connecting separate LANs 
together. Individual workstations are part of the LAN, and connected 
to the LAN is a dedicated server that processes internet communica- 
tions. 


Asynchronous connections 


Asynchronous wide area links are used in two types of situations. 
First, they are used to connect remote asynchronous terminals to a 
terminal port. Second, they can be used to connect PCs to an Ether- 
net using the asychronous version of DDCMP. 

Remote terminals (or a PC emulating a terminal) can be connected 
to any device that would normally have a locally connected RS-232 
cable. Modems have been standardized and can use the services of 
the dial-up telephone network at speeds of up to 19.2 kbps. Several 
modem standards exist, however, so it is important that the modems 
on either end of a connection share a common set of protocols. 

The remote end of the connection from the terminal, or terminal 
emulator, can be any device that would expect to see a terminal. This 
could be an asynchronous communications terminal on a VAX. It 
could also be a port of a terminal server. Either of the two ports 
would have a modem attached to it. 

It is important that the host controller have modem control enabled 
on it. This allows the port to detect when the signal has been ter- 
minated. Otherwise, users will hang up the phone when they are 
done without properly logging out. This leaves an open session on the 
system which is taken over without authentification by the next user 
to reach that port. This is especially a problem when the discontinued 
session had high levels of privilege and the user was cut off because of 
some technical difficulty. 

Asynchronous traffic, in the form of the DDCMP protocols in 
asynchronous mode, is also used to connect remote DECnet nodes 
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together. This is frequently used for connecting a PC to a remote VAX 
for limited periods of time. 

One of the features of DECnet/DOS is that it allows a port on an 
asynchronous communications controller on the VAX to dynamically 
switch over from being a terminal port to being a DDCMP data link 
port. 

The VAX device driver has two pieces. One piece is the user-de- 
pendent part, known as a class driver. In this case, there is a ter- 
minal driver and a DECnet driver. The lower part of the device 
driver, known as a port driver, is the device-dependent part. In this 
case, this is an asynchronous communications controller. 

The dynamic connection is established because the VAX has been 
programmed to detect a special escape sequence from the incoming 
terminal session. This signals the VAX to switch from using the ter- 
minal driver for that port to using the DNA driver instead. 

Instead of a VAX, a dedicated asynchronous router may be used. 
DEC sells the DECrouter 200 which consist of eight asynchronous 
ports. The router also has an Ethernet connection. This allows eight 
direct connections or eight modems to be placed on the router. This 
also allows non-Ethernet PCs to participate in the DECnet environ- 
ment. Of course, the line speed of each port on this DECrouter is only 
19.2 kbps which is significantly less than the 10 mbps that is used for 
Ethernet-based PC systems. 

The DECrouter 200 can participate on the Ethernet as a level 1 
router and is even able to become the designated router on the Ether- 
net. In fact, it is possible to disable all eight serial ports and use the 
device strictly as an Ethernet router. In this case, the device is able 
to forward up to 600 packets per second. 

With the lines enabled, the router usually is only able to forward 
less than 170 packets per second. This is an aggregate metric under 
optimistic loading conditions. 

A DECrouter 200 can be connected to any form of Ethernet connec- 
tion. It uses a standard transceiver cable and can be connected to an 
H4000 (baseband), DELNI (multiport transceiver), DESTA (ThinWire), 
or DECOM (broadband) transceiver. 

The DECrouter is a full member of the DNA routing configuration, 
with support for out-of-order packet caching and path splitting. Path 
splitting allows a manager to configure two lines of the DECnet 
Router going to the same location with the same cost. DNA routing 
algorithms send packets down both paths (if they are both up), thus 
acting as a form of load balancing. 

Often a VAX needs to provide outgoing asynchronous calls which 
are used to connect to online information services such as the Dow 
Jones News/Retrieval system. If modems are connected to a VAX, this 
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Courtesy of Digital Equipment Corporation 
Fig. 7-1 Rackmounted DF100 modems. 


can be accomplished using some VMS software from DEC called the 
VAX Public Access Communications. 

This software works with the DF series of modems as well as the 
Hayes series made by Hayes Microcomputer Products, Inc. The 
software is able to register phone numbers and then autodial them for 
users. DF series modems from DEC can be rackmounted in a machine 
room enviornment (See Figure 7-1). 

The software has built-in support for the Kermit protocols developed 
by Henson Associates, Inc., and distributed by Columbia University. 
Most online information services support downloading using Kermit as 
a file transfer protocol. 

Public Access Communications is also able to support session log- 
ging, which can be enabled or disabled using a special hot key. The 
information logged can be sent directly to a printer or can be put into 
a file. 

If several dial-out ports are available, the modems can be configured 
in a rotary, connecting the server to the next available port. The 
manager can restrict the use of connection features and can precon- 
figure numbers for users. 
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Later in this chapter, we will examine the use of the X.28 and X.29 
protocols as an alternative to point-to-point connections between the 
host and the terminal. X.28 connects an asynchronous terminal to a 
Packet Assembler/Disassember on an X.25 packet switched network. 
The PAD then communicates using the X.29 protocols to a host also 
connected to the X.25 synchronous network. 

It is possible to use Public Access Communications to allow a host to 
emulate a terminal. This is then fed into the local point of access for 
an X.25 network, such as Telenet or Tymnet, which passes the connec- 
tion through to the remote end. 

This strategy is often used as an alternative to placing long distance 
calls directly to online information services. Hosts are able to access 
their local point of access for the X.25 network which provides a 
cheaper way of connecting to these remote services. 


Synchronous Connections 


Point-to-point links between two VAXs are usually done with a 
synchronous form of DDCMP. This requires a synchronous com- 
munications controller in each VAX that supports the DDCMP 
protocols. These controllers are available from DEC as well as many 
other vendors. The controller needs to match the peripheral bus type 
of the VAX being configured. For example, a DMB-32 is a DEC con- 
troller that is BI-bus compatible and can thus be used on any of the 
8000 series of VAX computers (See Fig. 7-2). 

A DMB382 is a general-purpose synchronous device able to support 
different synchronous data link protocols. This controller can perform 
a many of the transmission, reception, and framing tasks of the data 
link layer as well as calculate the FCS. It is important to remember 
that any device controller will consume a portion of the CPU’s resour- 
ces. A DMB382 is able to process synchronous data at rates ranging 
from 4800 bps to 64 kbps. 

Depending on the speed that the DMB32 is run at, it uses a portion 
of a VAX’s resources. DEC has a metric called a load unit that is 
supposed to represent “average” use of resources. Each device operat- 
ing at a certain speed represents a number of load units. A particular 
size VAX also has a capacity expressed in load units. For example, the 
DMB32 has the following load unit table: 


DEVICE: DMB32 
SPEED 4.8 9.6 19.2 48.0 64.0 
LOAD UNITS 9 18 36 90 120 
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Courtesy of Digital Equipment Corporation 


Fig. 7-2 A DMB32 and distribution panei. 


A VAX 8250 has a maximum capacity of 125 load units, while an 
8700 has a capacity of 700 units. Using this metric, only one 64 kbps 
processor could be used on an 8250 without using all the capacity. 

It is important that this metric represents average packet sizes, 
average loads, and a variety of other averages. A true measurement 
of usage is very application specific and can usually only be measured 
based on historical data. 

For MicroVAX systems, the DSV11 provides synchronous services 
analogous to the DMB382. The DSV11 is a_ general-purpose 
synchronous communications controller. It can be used for SNA con- 
nectivity using the SDLC protocols or X.25 connectivity using the LAP 
B data link protocols. In a DDCMP environment, the board can be 
configured to operate with a single line at 256 kbps, or two lines at 64 
kbps. 

It is not unusual to configure a MicroVAX as a dedicated routing 
node on an Ethernet. This configuration would have a DEQNA Ether- 
net adapter and a DSV11 DDCMP board. Ethernet nodes, such as 
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Fig. 7-3 Ethernet-based routers. 


PCs or other VAXs, can then use the dedicated MicroVAX to reach 
other areas of the DECnet. The advantage of this approach over the 
dedicated gateway is that the MicroVAX can then be used for other 
functions. Figures 7-3 and 7-4 illustrate various routing configura- 
tions. 


Synchronous terminal links 


A second use of point-to-point links is for terminal traffic. When many 
terminals are all located at one site, it does not make sense to have a 
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Fig. 7-4 Three types of routers. 


separate dial-up line for each device. Instead, a multiplexer is used to 
concentrate all the traffic onto one line. This line might still be dial 
up, or it could be a leased line. 

At the other end of the connection, another multiplexer demul- 
tiplexes the traffic back out into separate data streams. The lines are 
then fed into an asynchronous communications controller. It is pos- 
sible for the multiplexer and the communications controller to be built 
into a single device. 

An example of a combination of a multiplexer and an asynchronous 
communications controller is the MUXserver 100. The MUXserver 
100 is a combination of a DEC DFM series multiplexer and a 16-port 
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terminal server. Remote traffic is concentrated onto a DDCMP 
synchronous line and is then demuxed by the MUXserver 100. 


Network-to-network connections 


Dedicated routers are devices used to bridge a particular local area 
network to a wide area environment. The DECrouter 200 is an ex- 
ample of such a device which was able to provide an asynchronous 
DDCMP service. This is suitable for connecting a PC or MicroVAX to 
an Ethernet for occasional traffic. 

For more demanding situations, synchronous routers are needed. 
The DEC Communications Server (DECSA) is an Ethernet-based 
device that is able to provide synchronous routing services (See Figure 
7-5). The routing could be to another Ethernet or to a host that can 
support synchronous data transmission. 

The DECSA communications server uses a modular approach. Up 
to 16 line cards can be put in the device. Aggregate throughput on the 
device is limited to 512 kbps. It could thus have a single 512 kbps 
V.35 connection or dual 256 kbps V.35 connections. Another option is 
32 V.28 connections (2 per card), each operating at 19.2 kbps. 

Protocol Assist Modules (PAMs) are used to boost the performance 
of synchronous line cards. A single PAM can support up to 16 line 
cards and there can up to 2 PAMs per DECSA. 

The 512 kbps total throughput of the DECSA is a metric based on 
average data. Several factors can change these throughput estimates. 
First, the router can be configured as a level 1 or level 2 router. If 
configured as a level 2 router, aggregate throughput will be less than 
500 kbps. Another factor is whether the DECSA functions as the 
designated router for an Ethernet segment. 

A successor to the DECSA is the DECrouter 2000, also known as a 
MicroServer or DEMSA. While the DECSA is based on a PDP ar- 
chitecture, the DEMSA is based on the 32-bit MicroVAX II chip set. 
Like the DECSA, this same device can also be used for X.25 or SNA 
traffic. For SNA applications, the device must be dedicated. X.25 and 
DNA traffic, however, can be mixed on a single DEMSA processor. 

While the DECSA is able to support packet-forwarding rates of 150 
packets per second in a DNA environment, the DEMSA provides the 
potential for up to 1500 packets per second. Also, because it is based 
on the more general MicroVAX architecture, upgrades to communica- 
tions functionality can be accomplished more easily. 

The initial release of the DEMSA supports an aggregate bandwidth 
of 256 kbps links configured in any combination of one to four 
synchronous lines. There is no reason why this basic configuration 
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Courtesy of Digital Equipment Corporation 


Fig. 7-5 A DEC communications server. 


cannot be upgraded in successor models for higher bandwidths by sub- 
stituting higher-performance communications controllers. 


General purpose communications servers 


The same DECSA communications server can be used for a variety of 
purposes. The use of a single hardware platform as a general purpose 
communications server is an important development. It allows the 
network manager to add bandwidth and protocol suites as needed 
using the same piece of hardware. 

Many other vendors are also working to provide a general-purpose 
communications utility. This allows a series of routers to form a 
general-purpose communications backbone for many different types of 
subnets. It would not be unreasonable to see the same MicroVAX II- 
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based system process and route data for different networking environ- 
ments, such as X.25, SNA, TCP/IP, and DNA. 

Another example of such a general-purpose communications utility 
is the Sun Microsystems SunLink product. SunLink is a synchronous 
communications utility that can downline load various protocol suites, 
including OSI, SNA, X.25, TCP/IP, MAP, and others. Because the 
protocols are stored in software and then downline loaded at run time, 
the same board can serve different users as needed. 

What makes the SunLink products especially useful is that a Sun 
Workstation supports all three major upper-level protocols used on 
Ethernet: DNA, TCP/IP, and XNS. This one workstation is thus able 
to route through traffic on behalf of any local area users to any of the 
various wide area protocol suites that are supported. 

A similar multipurpose solution is provided by the Proteon p4200 
router series. These routers are able to connect to Ethernet systems 
as well as to 4-mbps token rings and their own proprietary 80-mbps 
token rings. All three subnetworks are then connected together with 
the p4200 router series. 

In contrast to wide area bridges, the Proteon routers are able to 
accept routing information from upper-level protocol users. The same 
device, for example, is able to process Internet Protocol traffic at the 
same time as it processes DNA packets. Each packet is forwarded 
based on the network architecture that it uses. 

There are a few limitations on these routing capabilities. For the 
TCP/IP environment, the routing update protocols are RIP for interior 
gateway protocols and EGP for the external protocol. For DNA, the 
p4200 series can only function as a level 2 router. This makes sense 
as both DNA level 2 and IP use static routing tables. 

Many sites combine a variety of different types of equipment to form 
a flexible link between their LAN and wide area facilities. The dif- 
ferent types of equipment have complementary capabilities and 
together are able to form a general-purpose routing interface. 


Wide area bridges 


An alternative to using routers for wide area communications is to use 
an extended Ethernet that supports wide area communications. 
Routers provide a great deal of control over forwarding decisions but 
do so at a performance cost. This is because each packet must be 
examined for all of the functions of the routing layer. 

Bridges allow a packet to be forwarded at the data link layer. This 
allows the routing layer to treat the extended Ethernet as a single 
subnetwork in which every node is one hop away. Wide area bridges 
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thus perform the same function as LAN-based bridges, but they ex- 
tend that functionality to wide area links. 

One of the most popular wide area bridges is the TransLAN device 
manufactured by Vitalink. DEC makes extensive use of Vitalink 
products, both internally and by remarketing the products. The basic 
TransLAN device consists of an Ethernet controller and a series of 
synchronous line interfaces. 

The TransLAN device consists of a single Ethernet connection and 
eight wide area synchronous data links. Up to nine networks can thus 
be connected to a single bridge. This is a marked difference from the 
one-to-one connections supported by LAN bridges. Wide area bridges, 
because they are able to make routing decisions among multiple net- 
works, introduce a new level of complexity. For this reason, these 
devices are called “brouters” in marketing-speak, signifying that the 
layer 2 bridges are able to make some layer 3 routing decisions. 

The eight wide area links on the TransLAN can go to eight separate 
networks, or can provide multiple paths to a single network. By 
having multiple paths to a network, it is possible to provide redundan- 
cy in case of a line failure. Needless to say, it is recommended that 
the common carrier provider be instructed to route these two lines 
through different paths. Otherwise, a single backhoe can easily 
destroy any fault tolerance by destroying both the main and the alter- 
nate connection with one poorly placed trench. Remember, not 
everybody calls the telephone company before they dig. 

Extended Ethernets allow connectivity, but at the expense of 
bandwidth. While a local bridge can supports speeds of 10 mbps, the 
wide area bridge is not usually connected at speeds of more than 1.544 
mbps. Often, 19.2 or 56 kbps lines are used for the connection. 

The implication of the significantly lower bandwidth is that exten- 
sive internet traffic can quickly swamp the buffers in a bridge. 
Vitalink provides a series of filtering mechanisms used to implement 
policies that segregate certain types of traffic to local networking en- 
vironments. 

Filters are set up on the basis of network groups. A network group 
consists of all lines from one bridge terminating in the same remote 
bridge. Filtering is accomplished when the packet is received, fol- 
lowed by the decision to route the packet among a particular line in a 
network group. 

Filters are set up based on the packet contents. Usually, this con- 
sists of excluding traffic based on protocol types. It is also possible to 
establish filters based on incoming or outgoing addresses. Finally, ar- 
bitrary filters can be set up based on a template that examines ar- 
bitrary fields in the packet. 
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Filters are most commonly used as a method of including or exclud- 
ing certain types of traffic from a certain network group. Filters can 
also be used as a method of measuring types of traffic. An additional 
filtering feature is the low-priority queue. If this option is selected, 
received traffic is put into a special queue. Only after the queue for 
normal priority traffic is forwarded is this queue sent. 

An important feature of Vitalink bridges is that they are not neces- 
sarily limited to the Ethernet Media Access Control (MAC) protocols. 
Vitalink bridges exist for bridging token ring networks together. The 
IEEE MAC Bridge standard makes provisions for interconnecting dif- 
ferent MAC layers together into a single extended LAN. 

A multi-MAC LAN is only useful if the clients of the local area net- 
work speak the same network language. If, for example, TCP/IP is 
running in both environments, the multi-MAC LAN provides a sig- 
nificant level of connectivity. 


Using an extended Ethernet for LAT traffic 


One example of an extended Ethernet is DEC’s Easynet network used 
for internal data communications. A more extensive study of Easynet 
is provided at the conclusion of this chapter. 

Extended Ethernets are used by DEC in almost all of their sales 
regions as a way of connecting different subnetworks together. While 
the extended Ethernet could be used to carry DNA traffic, a policy 
decision has been to limit wide area extended Ethernet links to LAT 
traffic only. 

This decision was based on control and performance considerations. 
Routers provide a higher level of control and security than a bridge. A 
parallel wide-area routing network is provided to carry DNA traffic. 

The extended Ethernet serves as an extended terminal network. 
Figure 7-6 illustrates one of the extended Ethernets used by DEC in 
the mid-Atlantic region. A series of Tl and 56 kbps links are used to 
connect remote locations. In addition, the Washington area hub in- 
cludes a variety of fiber-based bridges. Not shown on the diagram are 
a large number of local bridges. Also not shown is the parallel 
Easynet routing network for DNA traffic. 

Performance is one of the major reasons for segregating traffic. The 
LAT protocols are designed to operate in a very short time frame, typi- 
cally 80 ms. Most of the wide area bridge links provide a link of 56 
kbps between different sites. Ifa DNA file transfer begins, it is easily 
possible for the bandwidth to be eaten up by DNA protocols, leading to 
late or undelivered LAT packets. This of course results in NAK mes- 
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Figure 7-6 A DEC extended Ethernet used for LAT fraffic. 
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sages, which generate even more LAT traffic, which further ag- 
gravates the situation. 


Using an extended Ethernet for general traffic 


A more general use of extended Ethernets is provided in a network 
maintained by VLSI Technology, Inc., of San Jose, California. VLSI 
makes application-specific integrated circuits. These are custom made 
for clients and manufactured in small quantities. 

VLSI maintains a series of design centers throughout the country, 
each of which is staffed by engineers and other design specialists who 
work with clients. Each design center consists of a variety of different 
workstations that use TCP/IP protocols. Design centers also have 
VAX computers and LAT-based terminal servers, using LAT and DNA 
protocols. Finally, Ungermann-Bass terminal servers use the XNS 
protocols. 

All of these design centers make extensive use of the computing 
facilities located at corporate headquarters in San Jose. Headquarters 
computing resources include the Elxsi 6400 superminicomputer, VAX 
11/785 and 8650 processors, HP 3000 systems, and a wide variety of 
other systems. Figure 7-7 illustrates a portion of the network. 

Links to headquarters are used for electronic mail, order entry, ac- 
counting, and other administrative tasks. In addition, computer-aided 
manufacturing information frequently flows between design centers 
and corporate headquarters. This large volume of traffic requires a 
high amount of bandwidth that can operate in a protocol-independent 
fashion. 

VLSI chose to use Vitalink bridges as a common connectivity solu- 
tion. Some of these bridges use 19.2 kbps leased lines. The large 
design centers are all connected together using a satellite link. The 
satellite link provides 56 kbps between headquarters and design 
centers and 19.2 kbps in the other direction. In addition, another 
TransLAN bridge is used with a Tl microwave connection to the San 
Jose Design Center. 


Establishing a general purpose routing interface 


Many organizations prefer to isolate routing traffic from general-pur- 
pose processing for a number of reasons. First, they want incoming 
connections to be concentrated in one area to allow for greater control 
over them. Second, a lot of routing control information is exchanged 
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between these devices. It often makes sense to segment that traffic 
onto a single front end network. 

The San Diego Supercomputer Center is an example of such a 
general-purpose front-end system. The Supercomputer Center serves 
a variety of remote users, ranging from networks such as NSFnet and 
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Arpanet to dedicated network connections for affiliates of the center. 
Figure 7-8 illustrates the SDSC network configuration. 

The San Diego Supercomputer Center is one of five supercomputer 
centers that were financed by the National Science Foundation. Be- 
cause the Center is involved with NSF, it makes extensive use of wide 
area communications to provide access to supercomputing facilities to 
researchers located throughout the nation. 

Computing resources at the center are focused around a Cray X- 
MP/48 and a minisupercomputer made by Scientific Computer Sys- 
tems. Online storage is very expensive for both of these computing 
environments, so an extensive file management system was built 
around an IBM 43881 running the MVS/XA operating system. 

All three of these resources are connected together using a dual- 
cable Hyperchannel network. Each cable runs at 50 mbps. Running 
on the Hyperchannel is a proprietary network called SDSCnet. 

A Cray does not provide very useful interactive computing facilities, 
so the user interface to the computation servers is handled by a series 
of front-end VAX computers. These computers provide a wide variety 
of communications functions. 

The VAXs begin by providing print services to users. Large-scale 
laser printers from Imagen and Xerox are connected to a VAX 11/785. 
There is also a film recording unit made by DICOMED. The Cray and 
the DICOMED film recording unit are used by Disney Studios for 
some of their animation. 

VAXs are also used to connect dial-in terminal users. A 32-port 
rotary is connected to one of the VAXs. Users within the facilities of 
the SDSC can also connect directly to the VAX using a M/A COM data 
switch. 

The primary use of the VAXs is to provide a programming environ- 
ment for users to prepare jobs. All of the VAX systems share a com- 
mon file system in a VAX Cluster. In addition, all of the VAXs are on 
the SDSCnet system so they can access compute resources on the 
IBM, SCS, or CRAY environments. 

One of the VAXs has an additional high-speed link directly to the 
Cray I/O Subsystem (IOS). This allows for data transfer rates of up to 
4 Mbps from the 8350 memory up to the IOS. This direct link also 
bypasses the overhead of SDSCnet. 

Incoming remote users are connected to a front-end Ethernet. All of 
the VAX systems are also connected to the Ethernet. Note that this 
means that the 8350 is a member of four different networks: Ethernet, 
the CI bus cluster, the Cray link, and the SDSCnet Hyperchannel. 

Users access the front end network through a wide variety of remote 
communications devices. A series of Proteon and DEC routers provide 
dedicated links for 56 kbps and T1 lines. These lines could connect to 
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Fig. 7-8 San Diego Supercomputer Center. 


an individual host or to another router on a remote Ethernet. The 
Proteon devices are able to accept both TCP/IP and DNA traffic. 

This modular approach to remote wide area lines, separated on a 
front-end network, was not the first solution used by SDSC. The sys- 
tem began by using a series of PDP computers as front-end processors. 
These systems accepted a wide variety of leased-line and satellite 
links. The advantage of the separate front-end network in the current 
configuration is that it is conceptually much clearer and easier to im- 
plement. When the center started, however, dedicated routers were 
not advanced enough to handle the volume of traffic expected. 
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Tymnet users originally accessed the center using a 9.6 kbps link 
with a Packet Assembler/Disassembler which was then connected 
directly to one of the 11/785 VAX systems. The software used is 
DEC’s Packet Switch Interface (PSI). The migration path used was to 
install an X.25 server and thus off-load that functionality from that 
VAX. 

NSFnet is used to provide a link to the Internet environment. This 
in turn gives access to most major national laboratories, universities, 
and corporate computing networks. This means that NSFnet makes 
the resources of the SDSC available to most of the country. Needless 
to say, financial considerations serve to limit this potential user 
population to those who have sent in checks. 

The original link to the NSFnet backbone used PDP 11/73 proces- 
sors connected to two 56 kbps lines. This is being replaced by nine 
RT/PC systems linked to four T1 lines. The switch to the RT/PC is 
part of the revamping of NSFnet by the MERIT consortium, which 
includes IBM, MCI, and the University of Michigan. 


X.25 Networks 


X.25, like Ethernet, is an example of a subnetwork. To the user of 
X.25, every node on the subnetwork is one hop away. X.25 is a three- 
layer network architecture based on CCITT standards. These stand- 
ards provide a common method of transmitting data across national 
boundaries. 

X.25 is actually a family of protocols that define how a user of the 
network, known as a Data Terminal Equipment (DTE), communicates 
with the boundary of the network, known as a Data Circuit-Terminat- 
ing Equipment (DCE). Once a packet of information is presented to 
the DCE, the X.25 network routes the information to the DCE closest 
to the destination DTE. Figure 7-9 shows the basic components of an 
X.25 network. 

Internally, the X.25 network can be a complex routing topology. 
The details of this routing are outside of the scope of the X.25 stand- 
ards. X.25 details how information is presented to the boundary of the 
network. Routing within the network is up to the X.25 implementor. 
Because the routing is not visible to the user, the X.25 network is 
usually represented as a cloud. 

X.25 has some similarities with the local area networks discussed in 
the previous chapter. Both Ethernet and X.25 allow multiple devices 
to be connected to a subnetwork. Both Ethernet and X.25 allow the 
user of the service to treat all nodes as though they were one hop 
away. 
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In X.25, service is performed by establishing a connection. This is 
in contrast to Ethernet which is a connectionless-oriented datagram 
service. An X.25 connection can either be a permanent logical connec- 
tion or can be established dynamically. These dynamic connections 
last only for the length of the session and are known as switched vir- 
tual circuits. 


Wide Area Networks 185 


Two other sets of protocols supplement the basic X.25 model. The 
X.75 protocols are used to route traffic between X.25 networks. The 
boundary of the two networks is a Signaling Terminal Exchange 
(STE). The X.75 protocols define how traffic is routed between two 
STEs on the boundary of two X.25 networks. 

The last set of protocols are for asynchronous terminal access to an 
X.25 environment. X.25 is a synchronous environment—data is sent 
in packets. An X.3 Packet Assembler/Disassembler (PAD) is used to 
connect the asynchronous terminal to the synchronous network. 

Communication between the X.3 PAD and the terminal is defined by 
the X.28 protocols. Communication between the X.3 PAD and a 
synchronous DTE such as a host is defined by the X.29 protocol suite. 
The basic function of these protocols is to prevent each character from 
traveling in a seperate packet. 

The X.3 PAD is able to hold data from the terminal until a packet is 
full or a special character, such as a carriage return, is encountered. 
The X.38 PAD thus functions as multiplexer/demultiplexer for the net- 
work, much like the LAT architecture does in an Ethernet environ- 
ment. 


X.25 layers 
X.25 defines three different levels of operation: 


a The network layer 
ws The frame level (a data link) 
ws A physical level 


The frame level uses the LAP B protocols, which are a subset of the 
OSI HDLC data link protocols discussed later. At the physical level, 
X.25 uses the X.21 and X.21bis interface standards. 

At the packet level, X.25 provides a series of logical channels that 
are available to the DTE. During X.25 operation, these logical chan- 
nels are mapped to a virtual circuit, which can be either permanent or 
switched. X.25 thus provides a connection-oriented subnetwork ser- 
vice, in contrast to the connectionless Ethernet service. 

Flow control in this environment is independent for each of the two 
directions of the circuit. This allows different flow control buffer sizes 
for different capacity devices. Each direction has a window size estab- 
lished which determines the number of unacknowledged packets that 
may be outstanding. Each time a packet is received, the current avail- 
able window is opened up to the maximum allowed. Every time a 
packet is sent, the window is closed by one. 


186 DEC Networks and Architectures 


In addition to establishing window sizes, the two sides can establish 
maximum packet sizes. This process of determining the window and 
packet sizes is known as flow control parameter negotiation. 


X.25 and DNA 


Support for the X.25 protocols is provided either with a dedicated X.25 
gateway or by using the services of a general-purpose VAX. Dedicated 
X.25 gateways are based on either the DECSA or DEMSA architec- 
tures discussed in the routing section. 

A general-purpose VAX can use an X.25 network as well. The VAX 
needs a synchronous communications board that can support the LAP 
B protocols. On a MicroVAX, for example, this might be a DSV11 
communications controller. On a larger system with a BI bus, this 
might be a DMB32 communications controller. 

Access to the X.25 environment is provided through the Packet 
Switch Interface (PSI) software. PSI drives the communications board 
and provides packet layer control for establishing virtual circuits. 
Remote nodes on the DECnet can also access the services of PSI using 
the PSI Access software. PSI Access establishes a DECnet logical link 
to the PSI node, which in turn sets up an X.25 virtual circuit and 
maps that to the DECnet logical link. | 

The X.25 gateway node runs an X.25 Server Module, which is a 
DNA application, just like DAP or CTERM. DNA hosts that access 
these services run another program called the X.25 gateway access 
module. The server and access modules communicate with each other 
using the Gateway Access Protocol (GAP). The PSI Access software 
contains the X.25 gateway access modules. 

The purpose of the PSI Access software is to allow a program to be 
shielded from the intricacies of X.25. Generic calls to the access 
module, such as OPEN PORT, are then mapped into a series of GAP 
commands that can open virtual circuits, make calls, accept or reject 
calls, and transfer data. 

X.25 can be used three different ways in the DEC environment: 


w As a DNA service provider 
s To allow DNA users to access remote hosts 
# To allow remote terminals to access DNA hosts 


As a DNA service provider, X.25 functions as a subnetwork acces- 
sible to the DNA routing layer. This allows X.25 to provide a link 
between two points, just like DDCMP or Ethernet. This line has a 
cost associated with it and the routing layer would choose to route 
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certain packets down this line based on factors such as congestion, 
cost, and availability of hosts. 

This true integration of X.25 into the DNA architecture has some 
limitations in Phase IV. In Phase IV, only permanent virtual circuits 
can be used as a data link service provider to the DECnet routing 
layer. In Phase V of DECnet, there will be a definition for a dynami- 
cally established data link (DED). This will allow a switched virtual 
X.25 circuit to be established upon demand. Note that this DED 
facility will also allow dynamically established DDCMP links to be es- 
tablished, including support in the architecture for the commands 
needed to activate a modems and dial a number. 

The second way to use X.25 in the DNA environment is as a tool for 
establishing a connection to a heterogeneous environment. In this 
case, the X.25 connection is not used to carry DNA traffic. Rather, the 
X.25 connection is used as a way of connecting a local user on the 
DECnet to some non-DNA host. X.25 really just serves as the 
equivalent of dialing up the host with a modem. 

A third use of X.25 is as a method of connecting remote terminals on 
the X.25 subnetwork to DNA hosts. The terminals are connected to 
an X.38 PAD, such as DEC’s DFM X.25 Packet Assembler/Disas- 
sembler. A VAX or X.25 gateway is then connected to the subnetwork. 
The PAD is able to establish a switched virtual circuit to the gateway 
node, which then passes the user through to other nodes on the 
DECnet that have the PSI Access software. 


X.25 optional facilities 


Several facilities that are specified as optional in the X.25 standards 
are supported by DEC on their gateway facilities. These options in- 
clude: 


a Closed user groups 
w Call redirection 
= Security and charging options 


User groups provide a measure of security. A closed user group 
(CUG) limits either outgoing or incoming access to a DTE to a specific 
group of users. This allows the manager to limit the users on the 
local network that may place outgoing calls. It also allows the ability 
to limit remote users. 

A special type of closed user group is the bilateral CUG. This al- 
lows pairs of DTEs to connect but limits calls from DTEs that have 
not formed this bilateral arrangement. 
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Call redirection is used when a DTE is out of order, busy, or just 
plain antisocial. The call redirection facility allows calls to be 
redirected to a single target DTE or can provide suggestions of alter- 
native DTEs to try. Note that this doesn’t mean that the suggested 
DTE will accept the call. The standard allows calls to be continually 
redirected until the calling user gives up and slams the phone down in 
disgust. 

A network user ID allows a DTE to provide authentification infor- 
mation with a call. When an incoming call is received, it is possible 
that the DCE will reject it based on unsatisfactory information. This 
prevents an undesirable user from gaining access to the system (un- 
less of course they are able to impersonate a valid user). 

Call charging allows charges to be imposed on the network. A 
reverse charging acceptance facility allows a DTE to specify that it 
will accept collect calls. A local charging prevention facility prevents 
the user of a DTE from initiating a call that will be locally charged. 

Most charges on an X.25 network are a function of the amount of 
data that was transferred, both the number of bytes and the number 
of packets. Often, this information is not presented to host DTEs until 
the end of a billing cycle. If the host DTE wishes to use this informa- 
tion for billing purposes, it needs some estimate of the amount of traf- 
fic. The charging information facility allows a DCE to give the DTE 
using this facility information it needs to calculate bills. 


ISDN 


The Integrated Services Digital Network is another example of a sub- 
network. Like X.25, connection oriented services can be set up be- 
tween any two points on the boundary of the network. 

ISDN, like X.25, defines the access protocol to the edge of the wide 
area network. Within the network, a related set of protocols, Signal- 
ing System 7, are used to allocate bandwidth, manage internal signal- 
ing, and recover for a digital network. 

This book uses the term ISDN fairly loosely to refer to both the 
ISDN access protocols and the internal SS7-based communications 
network. Users on both ends of this network see the ISDN protocols, 
even though another protocol is being used inside of the network. 

ISDN provides greatly enhanced capabilities over more traditional 
subnetworks such as X.25. The basic principle of ISDN is to allow 
users to share a common transmission media for different functions. 
Voice, video, and data all can be transmitted on the same digital lines. 
These lines are available in increments of 64 kbps and are known as B 
channels. 
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Signaling and management in the ISDN environment is done over a 
separate line called the D channel, which operates at 16 kbps. In 
addition to providing out-of-band signaling, the D channel is able to 
accept X.25 packets and telemetry information. An example of a 
telemetry application is a remote alarm for a security system. 

An end user of the ISDN network will typically have a Basic Rate 
Interface (BRI) to the network. This consists of one D channel and two 
B channels (2B+D). The entire BRI interface can run on four wires. 
The ISDN protocols define a time division multiplexing protocol so the 
B and D channels are all able to access the physicial medium. 

Larger organizations will have a Primary Rate Interface. This con- 
sists of 24B+D in North America and 30B+2 in the Europe. 24B+D 
corresponds to the T1 standard of 1.544 mbps in the United States, 
while the 30B+D corresponds to the other standard bandwidth alloca- 
tion in the world of 1.984 mbps. 

In both the BRI and PRI interfaces, the D channel is used to control 
the bandwidth on the B channels. The B channel is totally 
transparant and appears as a physical wire to the user. On top of the 
B channel, the data communications user might run DDCMP, SDLC, 
LAP B, or any other data link protocols, as well as voice or other 
nondata traffic. 

ISDN defines two protocols that run on the D channel. LAP Disa 
data link protocol that provides multiplexing support. Protocol D cor- 
responds to the network layer of the protocol stack and allows connec- 
tions to be established and other control information to be exchanged. 

An important way that ISDN differs from X.25 is that the internal 
routing of the network is defined. The LAP D and Protocol D define 
the interface to the edge of the network from the ISDN terminal. 
Another protocol, Signaling System 7 (SS7) defines how traffic is 
routed within an ISDN network. A common signaling system allows 
seperately administered ISDN environments to provide a unified com- 
munications environment. 


LAP D protocols 


The D channel in ISDN is crucial because it provides the signaling 
mechanism available for multiple different connections. Note that the 
B channels do not have any data link or network layer protocols 
defined. This is because they provide transparent bandwidth for use 
by different types of applications, such as voice traffic. 

The D channel defines both a data link and network layer. The 
data link layer uses the LAP D subset of the HDLC protocols. Access 
to this D channel is based on a variant of the CSMA access protocols - 
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used in Ethernet. Like Ethernet, multiple nodes can access a common 
D channel and can sense if others are using the network. Rather than 
waiting for a random period of time after a collision, HDLC uses a 
contention resolution mechanism similar to that used in the CI bus on 
a VAX Cluster. 

Then, each node wishing to transmit listens for a consecutive num- 
ber of free line indicators. Different nodes can have a different 
parameter for this free line indicator (i.e. eight consecutive 1s on the 
line instead of nine). After a node has transmitted, it ups its free line 
indicator to allow others to access the network. 

Note that the D channel is actually sharing the physical medium 
with the B channels so the term “line” is somewhat of a misnomer. 
The access method to the physical medium makes the D channel ap- 
pear as though it were the sole owner of a physical wire, but in reality 
it is sharing time slots with the other channels. 

The LAP D protocols add several important functions to the LAP B 
protocols used in X.25. Most importantly, LAP D allows several dif- 
ferent data links to be multiplexed on a single D channel. This moves 
the multiple access function down from the network layer into the 
data link layer. This also allows a broadcast mode to be supported 
between the multiple data link users. Another important improve- 
ment is the addition of a permanent supervisory function on the chan- 
nel. 

A LAP D frame begins with a flag indicating the beginning of a new 
packet. This same flag is appended at the end of the LAP D packet. 
After the beginning flag is an indicator of the type of packet (signal- 
ing, information, control) being sent. This is followed by an address 
field and some control information. 

The content of the control field depends on the type of frame being 
sent. For a normal data (information) frame, the control field contains 
two sequence numbers. The first sequence number is the number of 
the frame being sent out. The second sequence number is that of the 
last frame received from the other side of the connection. This 
prevents unnecessary acknowledgment frames from being sent 
through the network. 

Error control is done through the use of acknowledgments. Normal- 
ly, returning data would contain the acknowledgment. Otherwise, a 
special supervisory frame can be sent which contains a sequence num- 
ber of the next frame expected. If no acknowledgment is received 
before a timer elapses, the frame is resent. After several consecutive 
transmissions, the data link layer gives up and sends a notification up 
to the network layer user. 

Idle nodes periodically send out RECEIVE READY frames on the data 
link. This is because multiple users can share a LAP D channel, and 
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therefore it is impossible to tell at the physical level if a node is still 
active. These RR frames contain a sequence number of the next frame 
expected. A special management function is used to identify every user 
of the D channel. This is done by requesting an identity when a new 
user joins the channel. 


Protocol D 


Protocol D is a network layer protocol that runs on top of the LAP D 
data link protocols. In OSI terms, Protocol D is a subnetwork access 
procedure. Higher sublevels of the network layer would provide rout- 
ing and other traditional network layer functionality. 

An important consequence of separating the subnetwork access 
routines from the rest of the network layer is that multiple entities 
can now access this subnetwork. Thus, the OSI data communications 
environment might use Protocol D to set up X.25-like virtual links on 
the D channel or to allocate B channel bandwidth. Another user 
might be a voice telephone user, who would request a B channel cir- 
cuit for voice transmissions. 

Protocol D is used to set up and manage a call over the D channel. 
It is then used to supervise message transfer and detect faults on the 
underlying subnet. The call setup in Protocol D is very similar to that 
on a telephone system. 

The call begins by a user notifying the ISDN network that they wish 
to communicate with some foreign address. The ISDN addressing 
scheme is very similar to the current telephone numbering system. 
SS7 would then be used to establish a virtual circuit to the destination 
side of the ISDN network. 

The destination edge of the ISDN network would then ringing a par- 
ticular user of the D channel. This results in a call proceeding mes- 
sage on one side of the connection and a ring to the other side. 
During the call setup procedure, the network may send ring-back in- 
dications to the initiating user to indicate that setup is proceeding but 
the other side has not answered. Once the other side “answers” the 
call, a connect message is sent back through the network. 

During the call setup procedure, it is possible to have up to four 
user information messages sent in each direction. This allows the call 
setup procedure to include personalized welcome or authentification 
services. A typical use of the ISDN is thus to send the calling number 
in with the call setup procedure, as well as some supplementary infor- 
mation. The receiving end can process this information and route it to 
several users of the D channel. For example, an incoming call can be 
routed to the user’s voice telephone as well as notifying the user’s 
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database server of the incoming caller’s identity so the computer auto- 
matically pulls up a profile of the caller. 


Signaling system 7 


SS7 is the protocol used within the network for supervisory and con- 
trol functions. The SS7 protocols run on a 64 kbps data channel and 
uses the HDLC protocols discussed earlier. SS7 also includes a 
variety of upper layer functions such as security functions. 

The SS7 network architecture is divided into two parts. The net- 
work layer provides for connections among different signaling points 
in the network. The ISDN and public telephone networks can both 
use SS7 as a method of allocating bandwidth. Upper layer SS7 func- 
tions also use the SS7 network layer to exchange security and 
management data among signaling points. 

The network layer of SS7, known as the message transfer part, of- 
fers a set of services to the different upper-layer users. The network 
layer module is the manager of resources at a particular signaling 
point in the network. One of the prime functions of the network layer 
of SS7 is to monitor error rates on all lines currently in service and to 
terminate any lines with unsatisfactory performance. | 

If the user of SS7 is a telephone user. port, this will usually be used 
for a call setup function by sending an initial address message 
through the network. An enhanced version of the Telephone User 
Port definition allows user information to be transmitted with the call 
setup request. This information might include the extension of a call- 
ing party on a private PBX. It might also be used to directly specify 
the extension of the user who is being called. Finally, this user to user 
information may include authorization information. 

SS7, by providing a common signaling method, allows different com- 
mon carrier providers to easily communicate with each other. The 
impact of SS7 is that users of the ISDN see one common subnetwork. 
SS7 handles allocation of bandwidth, routing decisions, security func- 
tions, and other internal matters on the network. Protocol D and LAP 
D then define how the user interacts with the access device on the 
edge of this network. 


Use of ISDN 


ISDN provides many important enhancements to the present system 
of voice analog lines and the potpourri of data transmission facilities. 
Most important is the unification of voice, data and video onto a com- 
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mon transmission medium. This allows a common terminal to be used 
for a variety of functions, include FAX transmission, teletex, voice, 
data, television, and videotex. 

Just because the services are integrated doesn’t necessarily mean 
that the user will have a single device for all these functions. What it 
does allow is the coordination of the different types of resources. For 
example, when a telephone call is received, it may include the phone 
number of the called party. The receiving PBX would then perform 
two signaling operations. 

First, the call would be routed to a particular voice telephone. The 
telephone would automatically ring and display the phone number of 
the calling party. Call redirection could be performed or call waiting 
notifications sent if the terminal is already occupied. 

A second set of signals could then be sent to the user’s computer. 
This signal would contain the name of the calling user. The computer 
would then automatically call up the available information on that 
user and display it on the screen as the phone is ringing. 

Another application of ISDN is to allow the user facility to perform 
extended accounting. Calls received can be routed directly to the 
user’s terminal. In addition, an accounting computer can be notified 
and can log the call. 

Because multiple calls can be multiplexed, it is possible for a user to 
use an ISDN terminal to switch between multiple communications 
contexts. An example of this is putting one person on hold while han- 
dling another call. This allows the possibility of a new generation of 
telephone/data sets to become available. 

AT&T provides an impressive demonstration of this multiplexing 
capability. They provide an ISDN terminal which consists of an ISDN 
interface board for a PC and an ISDN-compatible telephone. A BRI 
interface is then provided to a 5ESS central office switch. The user is 
able to establish a voice call on one B channel and a 64 kbps connec- 
tion to a host computer on the second B channel. 

The D channel is then used to route X.25 traffic over to several 
other hosts. A single PC is able to have five or six different simul- 
taneous connections, including one 64 kbps high-bandwidth connec- 
tion, in addition to the 64 kbps voice connection. The X.25 support on 
the D channel is an example of a value-added service from the ISDN 
provider (in this case, AT&T). 

It is important not to overlook one of the simplest advantages of 
ISDN—tremendous bandwidth. Emerging fiber optic standards are 
providing gigabits of transmission capability between signaling points 
in the wide area network. ISDN allows users to quickly take ad- 
vantage of that bandwidth. For example, fax systems usually transmit 
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at 2400 to 4800 bps. A 64 kbps line could be used instead to transmit 
at significantly higher speeds. 


DEC’s CIT program 


DEC’s Computer Integrated Telephony is an architecture for integrat- 
ing PBX systems with the data network. While it does not assume the 
availability of an ISDN network, it does allow a smooth transition into 
that environment as facilities become available. 

CIT allows a CIT server to be connected to selected PBX systems 
that support CIT. The CIT server (a VAX) is connected at speeds of 
up to 64 kbps using the LAP B protocols to the PBX. CIT functions 
allow the server to make and answer calls, disconnect, and do other 
operations typically available to the telephone system. 

A CIT client module then makes the services of the PBX available to 
an application program. An incoming call would thus go to the server 
module, which would then send that information to the appropriate 
client module on the DECnet. The client module would notify the ap- 
plication program, which in turn might look the incoming number up 
in a database. Figure 7-10 shows a basic CIT configuration. 

Most of the functionality available depends on which vendor is im- 
plementing CIT support on their system. A function like BARGE IN for 
example, might not be available on each type of PBX. Likewise, RING 
BACK, which allows a connection to proceed as soon as the destination 
is free, is not necessarily available on each PBX or enabled for each 
user. 

A typical CIT system in an ISDN environment would have calls first 
routed to a central switching station, possibly with an attendant to 
answer the phone calls. Phone calls received would then be routed to 
the user’s telephone. At the same time as the call is routed to the 
telephone, the number of the calling party would be sent to the CIT 
server. The CIT server would notify an applications program, which 
would in turn pull up data on the incoming caller and send it to the 
user’s terminal. 


Wide Area Implementation: DEC’s Easynet 


A fairly amazing example of a wide area network integrating DEC 
equipment is the internal network for DEC employees. The network 
reached 25,000 nodes in 1987 and is continuing to grow. The network 
is used extensively for internal functions. Applications range from 
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Fig. 7-10 A CIT configuration. 


electronic mail for 80,000 users to videotex for distributing new sales 
information to file transfer for publications applications. 

The wide area portion of the network is a backbone utility that is 
available to a wide variety of different applications. The same back- 
bone is able to service voice traffic, video traffic, terminal access, and 
various DECnet routing traffic. The overall backbone bandwidth is 
manually allocated to accommodate the various demands. 

The core of the network is located in northern New England where 
most of DEC’s corporate facilities are located. The backbone in this 
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arena is a 200-mile fiber optic network connecting major facilities. Be- 
tween any two facilities there is a minimum available bandwidth of 45 
to 90 mbps. This bandwidth is allocated in standard T1 to T3 
modules. 

Fanning out from the corporate facilities is a general mesh of T1 
lines. Over 200 T1 lines span the United States and provide multiple 
paths to different locations in case of failure. T1 switches from Net- 
work Equipment Technologies, Timeplex, and several other vendors 
are used to allocate the T1 bandwidth to different applications. Com- 
pression on the switches allow more traffic to be accommodated. A T1 
line can be allocated as a single data path, or it can be divided among 
multiple 32 kbps voice or 56, 128, or 256 kbps data channels. 

The European portion of the network is a mix of 64 kbps lines and 
the European T1 equivalent of 2.048 mbps. Hubs in England, France, 
Ireland, and Switzerland link the individual countries to the backbone 
system. Satellite links of 64 kbps are used to connect Puerto Rico and 
the Orient. A series of 9.6 kbps lines are used for South America. 

The backbone network is used primarily for four types of applica- 
tions, although bandwidth can be allocated as needed for other uses. 
The primary applications are a terminal access network, a video net- 
work, a private telephone network, and of course the Easynet DECnet. 

The private telephone network is used to bypass the local telephone 
companies. The day that this network was activated, Bell Atlantic 
saw a significant drop in the volume of traffic on their network. The 
hub of the Digital Telephone Network is a series of four Northern 
Telecom SL-100 PBX systems. These PBX systems in Massachusetts 
and New Hampshire each have a total configured capacity of 30,000 
ports, although a normal configuration uses less than half of the 
potential capacity to allow for expansion. The PBX systems connect 
together in a mesh topology using the services of the backbone fiber 
optic facilities. 

The video network is used typically as a one-way video channel with 
two-way audio. This is used for presentations by senior management 
to multiple facilities. The network also has the capability to provide 
two-way video or teleconferencing. The video network is also used for 
new product announcements, press briefings, and training classes. 

The terminal access network is based on X.25. DEC uses a com- 
bination of the Tymnet public X.25 network and a private X.25 net- 
work built on top of the Tymnet facilities. Hosts connected to the 
network use DEC’s PSI software for connection. Terminals are con- 
nected to X.3 PADs. Over 300 X.25 nodes are used to transmit 7 bil- 
lion characters per month. 

The data network uses a series of dedicated DEMSA systems as 
dedicated routers. The DEC network consists of multiple DNA areas. 
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In the United States, regions are separate areas. In most of Europe, 
single countries or groups of countries constitute areas. In northern 
New England, several areas exist. Each area has one or several of the 
DEMSA systems as level 2 routers. 

A standard hardware configuration is used in most area routing 
sites. These “towers” consist of a machine rack that has several 
DEMSA DECnet Routers. The tower also has two MicroVAXs that 
function as the load hosts for downline loading software to the 
DEMSAs. Two MicroVAX systems are provided so that there is a 
backup load host. 

The areas tend to be Ethernets or extended Ethernets using the 
Vitalink TransLAN bridges. Over 250 separate Ethernets are set up 
on the Easynet. Each of the areas is separately administered by a 
regional network manager. 

Overall administration of the Easynet is through a central Network 
Control Center. This group monitors the Easynet backbone using the 
NMCC software and several custom programs that interface to the 
Network Control Program. NMCC and NCP are both discussed in the 
next chapter. 

The Network Control Center regularly collects DNA counters from 
nodes on the network. Circuit statistics are also monitored using 
devices such as modem control systems. The Network Control Center 
also monitors the number of user calls as a high-level indicator of net- 
work performance—loud users are an indicator of network problems. 

The data network also has several gateways to other facilities. 
AT&T and DEC, for example, share a gateway for mail interchange. 
Several other organizations are also able to interact with DEC for pur- 
poses of electronic data interchange. DEC also has several computers 
that provide online access to customers for purchases. 

Needless to say, most of the generally available network nodes such 
as the DEC Store for customers are carefully segregated from the rest 
of the network. Even then, security on the network is still a difficult 
chore. 

This network is able to link 482 DEC facilities and 15,000 additional 
home connections into one unified network. During the annual 
DECworld show, DEC adds an additional area that has 500 nodes for 
a period of 2 weeks. During that time, Email users goes from the 
normal 80,000 to add another 20,000 DECworld attendees. 

The Easynet system has become crucial for DEC. A corporate offi- 
cial estimated at one DECworld that the corporation would loose 2 to 
5 million dollars per day if the network were not available. An es- 
timated 3 million minutes was shaved off the DEC phone bill in a 
6-year period because of the wide availability of Email facilities. 
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Summary 


Wide area networks are increasingly shifting from a focus on connect- 
ing terminals to computers or computers to computers toward being a 
subnetwork access protocol. This could be a dedicated link between 
two subnetworks, as in the case of the Vitalink TransLAN bridges. 

A more general method is to connect the local subnetwork (the 
Ethernet) to a wide area subnetwork. Examples of wide area subnet- 
works are ISDN or X.25 implementations. This approach allows the 
user to decide who to communicate with. The network manager is not 
forced to predetermine the user populations that will be reachable 
through the use of dedicated lines. 

ISDN provides an order of magnitude increase in performance and 
flexibility for wide area networks. Bandwidth in increments of 64 
kbps is available using software commands. This bandwidth is 
flexible and can be used for voice, video, data, or any other purpose. 
Value-added services in an ISDN subnetwork provide gateways to 
more traditional environments, such as an X.25 packet switched data 
network. 
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Chapter 


DNA Implementation and 
Management 


Overview of This Chapter 


This chapter discusses two distinct types of issues. First, the details 
of implementing DECnet on particular operating systems are dis- 
cussed. VMS, Ultrix, and DOS all pose unique problems in im- 
plementing the functionality that was discussed in Parts 1 and 2 on 
network architectures. Although DECnet is heavily oriented toward 
the three DEC-supported operating systems, there are several third- 
party implementations of DNA on other operating systems. 

The second section of this chapter considers the problem of manag- 
ing the network. Most network management products use the VMS 
operating system as the basis for providing a user interface to network 
management capabilities. Network management involves two distinct 
types of issues. 

First, there must be a general model of the entities involved in net- 
work management. An entity might be a DDCMP module or a routing 
layer module or a DAP-speaking process. The network management 
architecture details the type of interface presented by entities to the 
network manager. 

Second, there needs to be a user interface able to interpret the infor- 
mation that is received from these various network management en- 
tities. As will be seen, Phase IV network management involves a 
variety of different interfaces for the different types of architectures. 
One program is used for monitoring DECnet nodes, another is used for 
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monitoring a LAT server, and a third is used for managing bridges in 
an extended Ethernet. 

Phase V of DECnet is able to unify all these different types of ar- 
chitectures into a single user interface. This is because network 
management has been generalized beyond the issues of DECnet to in- 
clude multiple architectures, including systems that are not tradition- 
ally network based, such as databases or operating systems. In addi- 
tion, the Phase V network management protocols have been extended 
to provide greater functionality. 


Implementation of DNA on VMS 


The VMS implementation of DECnet is closely tied into the other 
parts of the operating system. Most network services are part of the 
VMS source code and are compiled in with the operating system. Of 
course it takes the proper authorization code and software license to 
use the software. 

Most operations in a DECnet operation are identical to those used 
locally. QIO calls are used to read and write from the network as well 
as for local file and clustered file operations. The ASSIGN and 
DASSGN calls are used to assign channels in the network, in a 
similar way to their function in the file system. 

A node name in VMS can be used to signify a variety of different 
types of network access. The full specification for the nodename can 
contain access information or use the default access on the remote 
node: 


nodename::filespec 
nodename'username password account’::filespec 


Each VMS node contains a proxy log-in database. This is a one-to- 
one mapping between network users and a proxy account on the local 
system. Any logical link request that does not contain explicit control 
information is run in the proxy account’s authorization context. 
Several network services, such as FAL data access, also have default 
accounts used if there is not a proxy log-in. Note that proxy log-ins 
can seriously compromise network security, particularly in the case of 
proxy log-ins on privileged accounts. 

An interesting feature in VMS is that a file specification can refer to 
a foreign task. This allows the same user interface to be used for file 
access and for remote task execution. The three different forms of a 
“filename” are: 
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nodename::"file_ specification" 
nodename::"task=task_spec’ 
nodename::"n=object_number"” 


A task specification is equivalent to an object number 0. As dis- 
cussed in the session control layer, this information is passed to the 
session control module on the remote node so that it knows which 
higher level service to notify for incoming requests. 

Since the network and a file system both use a QIO interface, the 
user can make direct calls to either service. Another option is to use 
the Record Management Services (RMS) which can work with both 
types of services, network and local. RMS network file services in- 
clude the ability to access remote files in record or block mode as well 
as in sequential, relative, and ISAM files. 

Since a filename also can include a task specification, the RMS ser- 
vices can be used to communicate with a task as though reading and 
writing to a sequential file. All remote input and output from the task 
are assigned to a local logical name called SYS$NET. Thus to runa 
foreign task and display the results locally, the user would first open a 
file, then read the results: 


open node::"task=taskspec" 
type sys$net 


There are several ways that a task can become known to the net- 
work. The most frequent way is that the image is registered in a local 
database. NETACP will create a process in the appropriate context 
and run the task when it receives an incoming request. If an entity is 
not registered, NETACP assumes that the task is a command proce- 
dure and that the task is located in a default account. 

The VMS kernel has two components that do most of the network 
access. NETDRIVER is a pseudo device driver that receives QIO calls 
for reads and writes to the network. The second process, NETACP, is 
used for more compute intensive tasks such as start-up or shut-down 
of logical links. Figure 8-1 shows the structure of the VMS implemen- 
tation of DNA. 

In addition to the logical read/write capabilities, NETDRIVER also 
contains the bulk of the routing layer software for DECnet. 
NETDRIVER is a high priority process and stays resident to avoid 
process start-up times. 

NETACP is used to define and provide access to the volatile 
database, which is part of the virtual address space for the process. 
NETACP controls state transitions for the data link layer, the routing 
software, and for logical links. NETACP is also used to create the 
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Fig. 8-1 VMS DECnet processes. 


process for incoming logical links with no declared task. Finally, 
NETACP provides a mapping between DECnet and X.25 data links. 
Two other process are also implemented in VMS, both for network 
management. A Network Management Listener (NML) is a server 
that also maintains the permanent database for network management. 
The NML then uses the NICE protocols to communicate with a user 
interface process, usually the Network Control Program (NCP). If the 
Network Control Program needs access to volatile data, it still com- 
municates with the NML process. However, rather than providing 
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direct access to the volatile database, the NML process communicates 
with the NETACP process. 

A variety of data links are supported in a DECnet, including both 
802.3 and Ethernet Level 2. X.25 permanent virtual circuits can be 
mapped to a DNA data link. The CI bus can also be used for DECnet 
traffic. Finally, asynchronous and synchronous versions of DDCMP 
are supported. 

Asynchronous DDCMP is often used for PCs accessing a VAX as a 
remote DECnet node. This could pose a problem when DECnet use is 
mixed with non-DECnet (i.e., simple terminal emulation). VMS allows 
an incoming PC to dynamically convert an asynchronous line from a 
terminal line into a remote DECnet (asynchronous DDCMP) line. 
This is possible because DEC separates device drivers into a class 
driver and a port driver. 

The port driver is the portion that actually works with the physical 
line. The class driver provides the interface to the services that use 
the device. Multiple users of a port driver is similar to multiple net- 
working services (LAT, TCP/IP, DECnet) sharing the Ethernet class 
driver. 

To convert the line, VMS first sends an escape sequence to the PC 
which tells the PC to convert itself into a DECnet node. VMS then 
switches to the class driver used for that session. At that point, the 
VAX and the PC exchange routing layer initialization information. 


DECnet/VAX performance 


Performance of DECnet on a VAX is a function of the communications 
devices and the size of the CPU. DEC publishes a series of guidelines 
based on load units. Each device operating at a particular speed using 
average data is worth a certain number of load units. Each VAX has 
a capacity measured in load units. 

Three classes of devices are considered for DECnet on the VAX. 
The worst in terms of performance are non-DMA devices that require 
software to perform all functions. When a new character is received, 
an interrupt is generated by the communications device. The VMS 
system must stop processing and receive the character, place it in 
memory, echo the character back, then go back to the original job. 

It is very rare that a site would depend on a non-DMA device for 
more than a few incidental terminals. In a DECnet scenario, a non- 
DMA device might be used for an asynchronous DDCMP connection to 
a PC. It should be stressed that the same type of connection could 
also be made with a communications controller that does have DMA 
capabilities. 
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Direct memory access allows the controller to receive several pieces 
of data and then place them all into a portion of memory. This allows 
the controller to buffer the information and only call on the CPU when 
its attention is really needed. 

DMA devices fall into two classes. Some devices are able to access a 
portion of memory but still require the use of the CPU device driver to 
process the information at the data link level. A DMB32 is an ex- 
ample of such a device. 

The second, more advanced type of DMA device is one where the 
data link level is built into the firmware. An Ethernet controller is an 
example of a DMA device of this sort. Encoding and decoding packets 
can all be done at the controller level, only requiring CPU attention 
when the data is ready to be presented to the client of the Ethernet. 

The load units for each class of device (operating at various speeds) 
is as follows: 


Load Units as a function of Line speed (kbps) 


Device Class 9.6 19.2 56 >56 
DMA (DQNA) 
DMA (DMB32) 
non-DMA 


NA 
NA 


A VAX 8800 or 8700 both have total load unit capacities of 1200. A 
MicroVAX II has a capacity of 280, while an 11/780 has a capacity of 
240. Once again, it is important to stress that these metrics are very 
application dependent and are simply based on hypothetical average 
data transmission requirements. These numbers should be taken as 
firm only by families with 2.2 children and a dog named Spot. 


Implementation on Ultrix 


The Ultrix implementation of DECnet includes several modifications 
to the socket mechanism that is present in the 4.3BSD implementa- 
tion of Unix. Sockets are virtual ports on a Unix system that can 
communicate with other sockets. Sockets are organized into domains, 
such as INTERNET, UNIX, and DECNET. Domains are families of sock- 
ets that can talk to each other. 
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The original 4.2BSD implementation of sockets didn’t allow for 
programs to pass data or other access control information along with a 
connection request. It also didn’t allow a server to reject a requested 
connection with a reason. Both of these changes were made, as were 
extensions to the network management interface that allow circuits to 
be turned on and off, multicast broadcasts to be switched on and off, 
and counters to be gathered on various devices. 

The DECnet domain has two interfaces to the Ultrix socket inter- 
face. A stream socket interface does not sequence data and requires 
all data to be self-describing. This interface is not used by DEC- 
provided services but is implemented to allow user programs to be 
easily ported from other domains. The other interface is the se- 
quenced packet interface which provides an ordered delivery of data. 

DEC made two types of changes to Unix. First, several changes 
were made to the kernel to support the new domain. Two system calls 
were changed to increase the maximum data length from 112 to 1024 
bytes to allow the passing of connect information. The network device 
drivers were also extended to support counters and multicasting ad- 
dresses. 

The second major change was the addition of an object spawner. 
The 4.2 socket interface requires all possible targets to be running and 
listening. An object spawner accepts incoming requests and then 
either passes them to an existing process or activates (spawns) a 
process. 

In some cases, end-user processes bypass the object spawner. Keep- 
ing a process resident decreases the amount of start-up time needed. 
Also, the object spawner can only connect one process per socket. 
Thus, multisocket processes also bypass the object spawner. 

The Network Control Program is used to declare a server to the 
spawner. NCP may also notify the spawner of a default user account 
if no access control information is furnished with the connect request. 
The spawner then handles authentification, executes the desired 
process in the context of a user account, sets up the necessary socket 
connections, and redirects standard input and output streams toward 
the sockets. 

The network management interface had to be changed somewhat 
from the original Unix implementation. This is because in TCP/IP, 
the usual network protocols for Unix, there are only two network 
management files. These ASCII files contain address mappings and 
are never written to by TCP/IP. Instead, an editor such as VI is used 
to change these files. In DECnet, the NCP must work with several 
files and often writes to these files. Access to configuration files must 
be through NCP because they are stored as sequential binary files 
rather than ASCII text. 
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Upper-layer services are fairly similar to the VMS services. The 
data access protocols, virtual terminal, and mail services are all 
provided. An Ultrix gateway provides an interface to the TCP/IP en- 
vironment. This gateway is somewhat transparent, allowing access to 
destination nodes not on a DECnet as long as the name of the Ultrix 
gateway is known. The Ultrix gateway participates in both the 
TCP/IP and DECnet environments. Note that this has frequently 
been done by end users as a method of interconnecting two different 
environments. The Ultrix gateway simply eliminates the extra step of 
manually logging into the Ultrix gateway via DECnet, then using a 
TCP/IP command to interact with the other environment. 


Implementation on MS-DOS 


Implementing DECnet on an MS-DOS system is difficult because of 
the single-tasking nature of the operating system. DECnet makes 
heavy use of background processes for things like transmitting and 
receiving periodic routing and line confidence messages as well as for 
maintaining multiple network connections simultaneously. 

To support background processes, DECnet-DOS uses a scheduler. 
The scheduler is activated by either timer or communications inter- 
rupts. When a timer expires, the foreground application is interupted 
and the background network task is run. Another type is interrupt is 
when network communications are received, such as the receipt of an 
Ethernet packet. 

An interrupt automatically saves the current CPU state and the in- 
terrupt return address. Once the current application has been saved, 
the scheduler first performs the requested task and then examines a 
background process list to see if other tasks have registered themsel- 
ves as runnable. The foreground task is then rerun. For example, to 
process an incoming Ethernet packet, the system must save the state 
of the current foreground task. The data is then copied from the con- 
troller into a receive buffer. The controller is reset to receive the next 
message. 

With the incoming message processed, the scheduler then looks for 
immediate work to perform. Since a data link packet has just been 
received, the routing layer must process the receive buffer. After all 
immediate work is performed, the foreground task is given control 
again. 

Most of the application layer modules are similar to those of the 
other operating system implementations. For example, the Network 
File Transfer (NFT) program is a DAP-speaking utility used to send 
and receive files on the network. The File Access Listener is a DAP 
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server. If a PC user has the FAL process up and running, that PC 
can send and receive files to remote users. 

DECnet-DOS also includes a virtual disk and printer service in ad- 
dition to the NFT and FAL utilities. These utilities allow the estab- 
lishment of a virtual disk volume or printer at a foreign node. A vir- 
tual driver is then loaded at boot time in the MS-DOS CONFIG:SYS file. 
Communication is established in the form of a logical link that uses 
the DAP protocols. The virtual driver supplements the default driver 
in MS-DOS. I/O requests are either passed to the standard driver for 
local I/O or passed to the network disk utility for remote access. 

In addition to a single threaded CPU execution, I/O in an MS-DOS 
environment is also single threaded. This poses a particular problem 
for receiving mail messages because a mail message could easily con- 
tain more bytes than the background network process has memory for. 
The network process has no knowledge of the context in which the 
foreground process is executing I/O operations. 

Rather than receive a mail message, the PC uses the services of a 
VAX host as a post office. When an outgoing mail message is 
processed, the DECnet-DOS mail interface automatically inserts the 
address of the designated receive node rather than the address for the 
PC, then sends the message out using the message-handling protocols. 

To access the VAX that receives mail messages on behalf of a user, 
DECnet-DOS users are able to use a VT220 emulator. The terminal 
emulator allows PCs to emulate an 80- or 132-column terminal. This 
emulator implements both LAT and CTERM virtual terminal services. 
The LAT support allows load-balancing and other DECserver features 
on an Ethernet. The CTERM support allows the DECnet-DOS user to 
access any host on the DECnet. 

Physically, DECnet-DOS supports both DDCMP and Ethernet data 
link protocols. DDCMP links use the asynchronous version of the 
protocol at speeds up to 9.6 kbps in AT-based systems and 19.2 kbps 
in higher-end PS/2 models. Several Ethernet controllers are sup- 
ported, including those from DEC, 3COM, and MICOM-Interlan. 


DNA Clones 


Several vendors have provided other implementations of DNA on al- 
ternate platforms from the traditional DEC-supported operating sys- 
tems. Alisa Systems has provided an implementation of DECnet that 
runs on the Apple Macintosh. Technology Concepts, a Bell Atlantic 
subsidiary, has provided a variety of different implementations, in- 
cluding MS-DOS, Apple Macintosh, and several Unix-based systems. 
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Implementations of DNA on general-purpose computers are for 
Phase IV end nodes. In addition, many of these implementations sup- 
port only client versions of applications. Thus, Technology Concepts’ 
CommUnity provides a client version of the FAL process for the MS- 
DOS implementation as well as client versions of CTERM. Other 
nodes cannot log into or access files from a PC, but the PC can access 
other nodes. These limitations are understandable given the limited 
capabilities of the PC. 

A related series of products, VMS clones, are provided by Boston 
Business Computing. The combination of a VMS emulator and a DNA 
clone often provides a viable alternative to a VAX. An example of 
such an implementation is the Elxsi 6400 parallel processor. 

The Elxsi is a system consisting of up to 12 processor boards operat- 
ing in parallel. The basic operating system for the Elxsi is EMBOS, 
the Elxsi Message Based Operating System. This operating system 
works on a very high-speed bus and is able to address over a gigabyte 
of real memory. 

EMBOS provides the underlying base, on top of which several 
operating systems are implemented. Both System V and Berkeley 
versions of Unix can be run, as well as EMS, Elxsi’s VMS emulator. 
Each processor can run a different operating system, and the failure of 
one processor does not affect other processors. 

The VMS emulator allows source code from a VMS system, complete 
with VMS-dependent system calls and VMS extensions to the Fortran 
language, to be recompiled on the Elxsi. In addition, a version of the 
popular EDT editor is provided along with most of the common DCL 
commands. In other words, the Elxsi looks virtually identical to a 
VMS system as far as users are concerned. 

To supplement the VMS emulation, Elxsi also has an implementa- 
tion of a Phase IV DECnet node. Users can access the Elxsi using the 
usual CTERM and FAL processes. If the Elxsi log-in banner is 
changed to the same as that of a VAX, users won’t even know that 
they are on a non-VMS system in most cases. 

Other non-DEC versions of DECnet exist on powerful minisuper- 
computers such as Alliant or Convex. While VAX computers are 
suitable in many circumstances, these third-party implementations 
provide an important degree of flexibility to network managers. If a 
VAX is unable to provide the appropriate level of performance (at the 
appropriate price), additional heterogeneous equipment can be added.. 

DEC is well aware that end users of equipment demand alternatives 
to DEC computers. This push toward heterogeneous systems has 
pushed DEC, as well as other vendors, towards the OSI networking 
protocols. Since OSI is a vendor-independent set of protocols, in 
theory heterogeneous resources will be able to form a unified network. 
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Part 4 of this book discusses OSI and the impact of these standards on 
DEC networking. 


Phase IV Network Management 


Phase IV network management consists of a variety of products. 
Several are available to manage the Phase IV components, such as 
dedicated routers or VMS nodes. In addition, there are a variety of 
other products that are used for managing other architectures, such as 
LAT-based terminal servers and extended Ethernet bridges. 

This section begins by discussing the Phase IV network manage- 
ment framework. Next, the NMCC/DECnet monitor is discussed as a 
common interface to Phase IV network management. Finally, the al- 
ternative user interfaces are discussed. 

The next section of this chapter discusses the Phase V network 
management architectures as well as EMA, an important new user 
interface architecture that provides a common user interface for 
heterogeneous network architectures. 

There are several functions that are not present in the DNA net- 
work management layer. Accounting in a DECnet is the responsibility 
of the individual layers. On a VMS node, a file called NETSERVER.LOG 
supplements the VMS accounting utility to provide accountability for 
use of resources from remote users. 

Automation and protection against malicious use are two other func- 
tions that are not part of the network management layer. Some auto- 
mation is provided at the individual node, particularly with the advent 
of VMS version 5 and dynamic tuning of sysgen parameters. 

Security is also the responsibility of individual nodes on the net- 
work. Making security node based instead of network based is a 
deliberate design decision for DNA. There are no generally accepted 
methods of securing a network, but security on an individual computer 
system is a fairly well understood problem. 

It is possible to provide encryption over data links. This is in a 
sense a form of network-based security. However, it is up to the two 
nodes involved in the exchange to encrypt and decrypt the data. 


Management entities 


The DNA model is composed of entities and functions that operate on 
those entities. There are six kinds of entities in the network manage- 
ment model: 
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a A node is the basic entity in the network and encompasses CPUs as 
well as routers and other specialized types of computers. 

w An area is an entity that consist of groups of nodes. 

= Logging entities are used to keep track of a number of counters and 
events that the network manager may need. 

a A line is a physical communication path, such as a leased phone 
line. 

s A circuit is the logical communications path that is on top of a line. 
Circuits and lines are entities that connect nodes together. In the 
case of the Ethernet, there may be several circuits on one line. 

2 A module is a catch-all entity that doesn’t fit into the basic five clas- 
ses of entities. X.25 gateway functions and maintenance modules 
are both examples. 


Functions in the network management model are operations on en- 
tities. SET, CLEAR, SHOW, and LOAD are examples of functions. For 
particular combinations of functions and entities, there are a variety 
of attributes that are allowed. In the case of a node, for example, the 
network manager can SHOW the STATE, NAME, or ADDRESS of that 
node. Figure 8-2 shows selected attributed for a node. 

Network management can be distributed throughout the network. 
For the purpose of any one instance of the network manager, however, 
the function resides on one particular node. This node is the director 
node because it is the one executing the network management user 
interface. Other nodes are agents. Directors communicate with agents 
using the NICE protocols. There can be several directors communicat- 
ing with agents in the network. 

Because the data link and physical layers are closely coupled in 
DECnet, lines and circuits are usually considered together even 
though they are separate entities. A line corresponds to the physical 
layer of the ISO model and a circuit to the data link layer. 

Multipoint DDCMP lines and Ethernet are both cases in which mul- 
tiple circuits reside on one physical line. X.25 differs slightly because 
most of the processing for X.25 is accomplished in an X.25 gateway 
module. Thus, DECnet is not really aware of X.25 lines. 

Several user interfaces are available for network management. The 
two primary ones in DECnet are the Network Control Program (NCP) 
and the Network Management Control Center (NMCC). NCP is a 
command-oriented interface and is the original user interface to net- 
work management function. A more modern system is the NMCC, 
which makes more extensive use of graphics. Instead of issuing the 
NCP SHOW CIRCUIT command, the NMCC user can see a circuit go 
from green to red on a graphic representation of the network. 
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SELECTED NODE ATTRIBUTES 


COUNTER TIMER 


CPU 


DIAGNOSTIC FILE 


DUMP ADDRESS 


HARDWARE ADDRESS 


LOAD FILE 


PHYSICAL ADDRESS 


ADDRESS 


NAME 


MAXIMUM LINKS 


BUFFER SIZE 


Fig. 8-2 Selected node attributes. 
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The user interface communicates with the rest of the network 
management model by issuing calls to the network management ac- 
cess routines. The access routines translate these calls into local and 
remote access to network management data. Local calls are routed to 
the node’s local network management functions. Remote calls are 
translated into the NICE protocols and sent to a remote Network 
Management Listener (NML). The NML will in turn send the request 
down to the local network management entities on the remote node. 
Figure 8-3 shows the structure of the network management model. 

The local network management functions convert generic requests 
into operating system-dependent calls. They also provide an interface 
to several special purpose modules. The maintenance module controls 
the operation of the MOP protocols for downline loading. The physical 
and data link modules control their respective layers. The event log- 
ger is a sink for data that was requested to be collected by a network 
manager. The event logger can log data for the local node as well as 
information received from remote nodes. 

Typically, the NCP user will tell the remote Network Management 
Listener to set certain parameters. These requests are sent down to 
the local network management functions. Another typical request is 
to log certain information, where the NCP user specifies the location 
of a sink node. When information is logged, the remote node sends it 
back to the local event logger which processes the information. 

The Network Control Program user has four major types of func- 
tions available: 


1. The user can change relevant parameters, such as the circuit ID. 

2. The user can gather information through the use of an event logger. 

3. The user can control maintenance events such as downline loading, 
upline dumping, and triggering bootstraps. 

4, The user can test links and zero counters. 


Local network management functions can receive four types of re- 
quests. A local instance of a user interface, such as the NCP, may 
request information. A NICE request may received from another node 
via the local instance of the Network Management Listener. The 
NML may also issue requests on behalf of itself, as in the case of an 
NML being instructed to regularly collect certain information. Final- 
ly, the local network management functions may sense certain types of 
service functions automatically, such as in the case of a physical link 
watcher notifying it that a line has gone down. 
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LINK 
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Fig. 8-3 Phase IV network management modules. 
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Event logging 


Events may originate from any node on the network and from any one 
of the DNA layers. The system manager specifies which nodes to log, 
and the address of the sink node that will receive that information. A 
sink node is a place on the network to send an event. NCP would 
then examine that sink node for a record of past events. It is possible 
to specify several sink nodes for the receipt of information. 

On the sink node, the manager can specify a filter to dispose of 
certain types of information. The filter allows certain events to be 
disposed of. Other filters may redirect data of different types to dif- 
ferent repositories. Figure 8-4 shows an example of an event log. 

The event logger module consists of nine different types of com- 
ponents. This architecture is meant to reduce the possibility of an 
event logger overrunning the host node, as well as to allow events to 
be dispatched and processed on multiple nodes. 

Event queues are used in several different types of situations 
depending on the eventual destination of the information. The queues 
buffer information on a first-in-first-out basis. One module will fill a 
queue and another, separate, module will empty it. 

It would not be practical to require the filling module to hold events 
if the desired event queue is full. This would make the module fairly 
complicated for buffer management and error processing functions. 
On the other hand, it is necessary to take some action to specify that 
information has been discarded because of a full queue. 

If the queue is full, the filling module discards the event. It also 
makes sure that the last event currently on the queue is an event 
called EVENTS-LOST with a time stamp. The receiving module will 
then know the time that the first event was lost. 

To avoid overrunning a remote node and because different sinks 
may process events differently, no processing is done at the event log- 
ger. Raw events consist solely of an event code, the event identifica- 
tion, and raw data. 

An event processor turns this information into an event with the 
following fields: 


Event Code 
Source Node ID 
Sink Flags 
Entity Name 
Date/Time Stamp 
Data 
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DECnet event 4.14, node reachability change 
From node 3.921 (PIZAZZ), 20-SEP-1988 11:07:29.05 
Node 3.221 (NHTRO2), Reachable 


DECnet event 4.18, adjacency down 

From node 3.921 (PIZAZZ), 20-SEP-1988 11:07:33.49 
Circuit UNA-0, Adjacent node listener receive timeout 
Adjacent node = 31.248 


DECnet event 4.15, adjacency up 
From node 3.921 (PIZAZZ), 20-SEP-1988 11:07:36.60 
Circuit UNA-0, Adjacent node = 3.341 (PSI 


DECnet event 4.13, init failure, operator initiated 

From node 3.921 (PIZAZZ), 20-SEP-1988 11:07:36.60 
Circuit UNA-0, Adjacent node block size too small 

Packet beginning = 0D020000AA000400550D03AB00000300 
Received version = 2.0.0 


DECnet event 4.15, adjacency up 
From node 3.921 (PIZAZZ), 20-SEP-1988 11:07:51.53 
Circuit UNA-0, Adjacent node = 3.341 (PSI) 


DECnet event 4.15, adjacency up 
From node 3.921 (PIZAZZ), 20-SEP-1988 11:08.15.40 
Circuit UNA-0, Adjacent node = 3.218 (BIGE) 


DECnet event 4.14, node reachability change 
From node 3.921 (PIZAZZ), 20-SEP-1988 11:08:24.76 
Node 3.218 (BIGE), Reachable 


DECnet event 4.10, circuit up 
From node 3.921 (PIZAZZ), 20-SEP-1988 11:08:25.13 
Circuit DMC-0, Adjacent node = 3.921 (PIZAZZ) 


DECnet event 4.7, circuit down, circuit fault 
From node 3.921 (PIZAZZ), 20-SEP-1988 11:08:35.45 
Circuit DMC-0, Line synchronization lost 


Courtesy of Digital Equipment Corporation 


Fig. 8-4 An event log. 
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Like event processing, event filtering is only done at the sink node. 
Each sink type, such as a monitor, file, or console, may have different 
filters. A filter has a two-level structure. A global filter is maintained 
for each event class. Specific filters are also available for particular 
entities within an event class. The filtering algorithm first checks the 
specific filter, then the global filter. 

When examining logging, operations can occur on groups of sink 
sites. An NCP command can refer to all ACTIVE LOGGING to get a list 
of all sink types that are in the ON or HOLD states. Alternatively, the 
user can request all SIGNIFICANT LOGGING nodes which only returns a 
list of sink sites with significant activity. Nodes can also be qualified 
to only include certain areas, circuits, lines, modules, or nodes. 

Events are ranked by classes. A class 0 event is a network manage- 
ment layer event; a class 4 event is a routing layer event. Within the 
event class, there are event parameters for different entities. Each 
event is uniquely identified by a type number within the class num- 
ber. Event classes 480 to 511 are customer specific and can be used 
for user-written applications. 


Downline loading 


Downline loading is managed from the network management layer. 
This layer issues specific MOP commands, which are passed directly 
to the data link layer. This is different from other DNA functions, 
which are passed through the other layers of the network. 

Several requirements exist for a downline load: 


1. The target node must be directly connected to the executor node 
via a physical link. 

2. The primary MOP loader must be resident in the target node in 
bootstrap ROM. 

3. The executor node must have access to the file. The file can be 
local or remote on a host node via the FAL protocols. The file can 
be specified by the target node in the load request or can be looked 
up by the maintenance module. 


A load request can be initiated by either the target or executor node. 
Typically, the initiation is by the target node. The executor node’s 
link watcher would detect a target-initiated load request and pass it 
through to the network management module. 

The ROM of the target node usually contains a primary loader. The 
next program that is passed through from the executor node is a 
secondary loader. This may even be followed by a tertiary loader. 
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Finally, the operating system is passed down to the target node and 
the MOP operation is completed. 

The MOP protocols are also used for an upline dump operation. 
This is the reverse of the downline operation in that data goes from 
memory on the target to a file on a host system. 

MOP protocols are used by routers, bridges, terminal servers, and 
other dedicated devices sold by DEC. The MOP protocols are also 
used by cluster members to boot themselves up. A MicroVAX 2000 is 
a diskless node and would issue a MOP request over the Ethernet. 
Large VAX systems booting over a CI bus also use the MOP protocols. 


NMCC/DECnet Monitor 


The Network Management Control Center (NMCC) provides a more 
sophisticated presentation environment than the more traditional 
NCP. NMCC uses the same NICE protocols and event-dispatching 
techniques used to collect data in NCP. Instead of collecting that in- 
formation and presenting it to the NCP user, however, a more sophis- 
ticated type of processing is invoked. 

NMCC consists of two parts, a user interface and a data collection 
and storage portion. This allows the data (known as a kernel) to be 
collected by one or more data managers. From there, terminals or 
nodes located elsewhere on the network are able to access this kernel 
of information. Figure 8-5 shows the structure of the NMCC software. 

The user interface to NMCC allows data to be presented in a variety 
of graphic formats. For example, a topology of the network can be 
used to examine the status of different componenets. Lines or nodes 
that are not operational are shown in red on the map. 

Other graphic formats in NMCC allow histograms and tables to be 
used to examine historical data. One nice feature of NMCC is that 
several data requests can be outstanding. NMCC will periodically 
deliver new data to the user for all outstanding requests. The user is 
able to switch between various displays for the various data requests. 


NMCC data model 


NMCC defines five types of information that can be collected. The 
first three are data collected from the network itself. These include 
characteristic parameters that define the control structure of the net- 
work and status parameters that reflect the dynamic nature of it. In 
addition, counters are used, usually to summarize status parameters. 
Figure 8-6 shows some counters available on a network. 
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Fig. 8-5 Network Management Control Center structure. 


To supplement the three information types collected from the net- 
work, NMCC adds two more types. First, users can supplement the 
network information with a variety of user-friendly information known 
as reference data. For example, a node name can be supplemented 
with the name and phone number of the system manager of that 
node. 

The last type of data defines the various information available. This 
last type of information is then processed through the help portion of 
the user interface to let users know what data they can examine about 
the network. By providing meta-data, data about data, NMCC allows 
for easy extensibility. 
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NODE COUNTERS 


Seconds since last zeroed 
User bytes received 

User bytes sent 

User messages received 

User messages sent 

Total bytes received 

Total bytes sent 

Total messages received 

Total messages sent 

Total (NSP) connects received 
Total connects sent 

Received connect resource areas 
Maximum logical links active 


Aged packet loss 

Node unreachable packet loss 
Node out-of-range packet loss 
Oversized packet loss 

Packet format error 

Partial routing update loss 


Fig. 8-6 Selected DNA counters. 


The five basic types of information are supplemented by three 
derived databases. Summary data is added to prevent the accumula- 
tion of needless details. Statistical and topographical information is 
also derived from the base data. 

Each of these types of information is collected for the different com- 
ponents in a network. Components include systems, circuits, remote 
nodes, and wires. Wires are the physical instance of a particular line 
that a system uses. 

A particular combination of the different component types and the 
different types of information form an instance of data collection 
within the database. Since network management is a dynamic en- 
vironment, all of these records are further categorized by time of col- 
lection. 
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Time stamps for data are provided upon receipt by the NMCC ker- 
nel. This is because there is no provision for network-wide time 
synchronization in DECnet Phase IV. A special time value for data 
collected is current. When users request current data, they are given 
the latest data collected. As new information arrives, it is automat- 
ically dispatched. This is known as a news function and allows his- 
torical and real-time data both to be presented within the same 
framework. 


NMCC kernel 


The data collection portion of the NMCC is known as the kernel infor- 
mation manager (KIM). The kernel is able to respond to requests 
from multiple user interfaces. The kernel shields the underlying 
storage format of the data from the user interface and provides a 
uniform interface for both historical and real-time data. 

The actual data for NMCC is kept in an Rdb database. Rdb is 
DEC’s relational database management system. db presents a 
synchronous interface to users of the system. This means that the 
beginning of a transaction must be followed by each of the transaction 
statements and then terminated by an end of transaction. Rdb does 
not allow a single user to have multiple requests outstanding. 

A synchronous interface is not appropriate for a network manage- 
ment environment. A user may have several data requests outstand- 
ing and new data requests may be received at any time. To present 
an asynchronous interface, a software module called the logical 
database (LDB) is wrapped around Rdb and interacts with the KIM 
module. 

The LDB process is responsible for all transaction-related process- 
ing. As such, it is actually several different processes. Each of the 
LDB processes interacts with the underlying Rdb database. Each 
processes represents a separate transaction context for data requests. 

Three different kinds of modules work with the KIM data kernel. A 
Network Management Interface (NMI) is responsible for working with 
Network Management Listeners throughout the network. The NMI 
module is analogous to a data sink in the network management model. 

User interfaces interact with the NMCC protocol server (NPS). This 
allows the user interface to be located anywhere throughout the net- 
work. NPS and user interface processes communicate using an en- 
hanced version of the NICE protocols. The enhanced version is neces- 
sary because the NMCC database contains information that supple- 
ments the basic event/parameter/counter model of network manage- 
ment that NICE was originally meant to handle. 
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A report package is used to summarize data in the Rdb database. 
This information is extracted hourly from the Rdb database and sum- 
marized into historical files. The historical files are stored in a stand- 
ard binary format. 

Access to these historical files can be through the NMCC user inter- 
face (the DECnet Monitor) or through programs. Datatrieve, for ex- 
ample, could access these historical files as could any program that 
uses the Record Management Services to access data. 

Because the Rdb database is of finite size and because historical 
information is summarized in flat files, it is necessary periodically to 
purge the database of historical data. A special program that inter- 
acts directly with the Rdb database is available for that function. It is 
also possible for a database administrator to use all of the normal RdB 
DBA facilities to backup the database or monitor disk usage and other 
performance metrics. 


NMCC/DECnet Monitor 


The DECnet Monitor consists of three different modules. The data 
access module is responsible for interacting with different NMCC ker- 
nels, managing different request contexts, and caching data. The ac- 
tion module is responsible for processing that information into suitable 
screens of information. The presentation manager works with the dif- 
ferent types of terminals available. 

The data access module works with the kernel to present a stream 
of information to the action modules. The protocol interface deciphers 
incoming data and presents that information to a resource manager. 

The resource manager can have multiple requests outstanding and 
is responsible for matching responses to requests. The resource 
manager is also able to detect duplicates and cancel old read requests. 
In case of a disconnection, the request manager will automatically try 
to reconnect to a kernel. This is important in cases where the DECnet 
Monitor is running unattended. 

The data manager accepts information from the requests and caches 
it. When users cancel displays, the data manager passes that infor- 
mation on to the request manager. When data arrives in the cache, 
the data manager sets a flag to notify the users of that information. 

The action routines do most of the work in the DECnet Monitor. 
Incoming information is prepared for presentation to the user. Com- 
mands are parsed and then passed along as data requests. 

The parser in the action module is context sensitive. This means 
that commands are parsed in the context of previous interactions. A 
NEXT command is a prime example of context sensitive execution: it is 
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interpreted by the parser to mean a display of a particular screen 
(usually the next screen in a list of outstanding requests). 

Often an action routine is used to display real-time data. It is pos- 
sible that the data requested has not arrived in the cache before the 
first screen is sent to the presentation module. In this case, the action 
routine uses default values and then updates information as data ar- 
rives in the cache. 

The parser allows the user to request particular displays based on 
components in the database, relevant time periods, and information 
types. Through a combination of averaging and interpolation, it is 
possible to show data for any arbitrary time period. 

A special set of action routines is used to modify data in the kernel. 
They switch from an asynchronous to a synchronous mode of action, 
which means that all steps in the modification are processed serially. 
This prevents the user from issuing a command and, after several in- 
tervening actions, receiving an error message. 

In addition, the command parser is able to invoke the services of the 
report writer, exit to the operating system, or connect to different ker- 
nels. The command parser also maintains a help system similar to 
the VMS hierarchical help system. 

The presentation modules are used to manage a single screen with 
multiple display areas. A command area accepts new directives and a 
message area returns messages from the DECnet Monitor. The actual 
display consists of a data area and an identification area. The data 
area holds the screen constructed by an action module. The identifica- 
tion area shows what screen is being displayed, and may contain infor- 
mation on previous or subsequent screens. 

The actual format of the displayed data depends on the type of data 
that is requested. Maps are used for topographies. Forms, tables, and 
histograms are also available for displaying data. For maps, the par- 
ser is able to accept commands to magnify or zoom in the map or to 
pan to a different location. 


Other Management Interfaces 


This section will discuss a variety of other management interfaces for 
working with individual systems and other network architectures and 
components. 

The section begins by discussing two software systems for managing 
individual nodes on the network remotely. The VAX Cluster Console 
System allows operator functions to be performed remotely. The 
Remote System Manager allows system management functions, such 
as software updates and backups, to be performed remotely. 
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Next, several packages are discussed for managing the Ethernet, 
terminal servers, and bridges. The Ethernet managment package, 
ETHERnim, can be used to examine all traffic on the Ethernet and is 
protocol independent. Terminal server and bridge management 
software systems are used to manage those particular types of devices. 


VAX Cluster Console System 


This software allows a single console to manage a series of different 
VAX systems. Up to 24 VAXs or HSC controllers may be managed 
from a single console system. The software uses the remote console 
capabilities of the MOP protocols to make a MicroVAX appear to the 
remote system like a locally attached console terminal. Figure 8-7 
shows a VAX Cluster Console System configuration. 

The VAX Cluster Console System (VCS) runs on a MicroVAX or a 
VAXstation II/GPX. A fiber link is used to connect to each node. 
Fiber is used to isolate the traffic. The console system must be con- 
figured with at least 5 Mbytes of memory and a 70-Mbyte disk. 

Another way of connecting to remote nodes is to use the reverse 
LAT capability of a terminal server. An RS-232 cable is connected to 
the console port of the foreign device and to a port on the terminal 
server. That terminal server port is then connected to the VAX 
Cluster Console System using a LAT virtual circuit. 

Reverse LAT on a terminal server allows foreign devices, such as a 
Vitalink TransLAN bridge, to be managed from a MicroVAX. The 
TransLAN is otherwise managed with a local VT220 terminal. This is 
not terribly convenient if an organization has several bridges located 
in different portions of a facility. 

The software presents four different interfaces. Interactive users 
use an interface similar to the VMS monitor utility. This allows one 
or two nodes to be monitored. The interface can also search logs of 
console data to look for specific strings, such as system diagnostic mes- 
sages. 

To examine a particular node, the VCS can connect itself to the a 
member of the VAX Cluster system as though it were attached to the 
console of that node. This allows a single console to appear as though 
it were actually connected to all the console ports of the different 
nodes. 

A programming or access interface allows specific actions to be 
taken when an event occurs. When an event arrives, a predefined 
piece of user software is activated and information about the event is 
passed in. If a system crashes, for example, the user software might 
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Fig. 8-7 VAX Cluster console. 


activate a modem, call the system manager, and use DECtalk to in- 
form the manager that a particular node is sick and needs attention. 
The last interface is used to pass information to hard copy console 
terminals. One or several nodes can have their console logs redirected 
to a particular hard copy terminal. When this data is received, it is 
logged with the time received and the source node, and then it is sent 
to the appropriate console. In a large machine room, this feature al- 
lows a single hard copy console to be monitored by operators, instead 
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of requiring them to wear roller skates to check ue consoles peri- 
odically. 

An interesting feature of the monitor interface is the presence of a 
scan line file. This file contains a series of text strings. All incoming 
messages are compared against this scan line file to see if any of the 
strings occur in the message. If so, they are displayed on the monitor 
screen. The scan line allows high-priority console messages to be dis- 
played on the screen and lower-priority messages to be routed to the 
hard copy terminal. A tape mount request by a user, for example, 
would probably go to the screen. 

VCS requires a MicroVAX dedicated substantially to this function. 
It is possible to have extra CPU cycles available at times (during slow 
periods for example), but the real-time nature of this activity requires 
a guarantee of available resources. 


Remote System Manager 


While the VAX Cluster Console System provides remote operator func- 
tions, the Remote System Manager is used for remote system manage- 
ment. Remote management of workstations is particularly important 
because many VAXstations are used directly by end users with no sys- 
tem management training. RSM allows a single manager to perform 
backup and update functions for a variety of different clients. 

RSM clients can only have one server, and they are usually on the 
same Ethernet as the server. It would not be unusual to have the 
Local Area VAX Cluster (LAVC) boot node also function as the RSM 
server. The RSM software does not consume resources when it is not 
being used, and hence the boot member can easily function in both 
roles. 

One of the key features of RSM is that it allows backup to be 
automated among clients. This common backup is then used as an 
archive for the entire LAVC (or noncluster-based clients). Particular 
files can then be picked out of the backup set. 

A common backup environment makes a lot of sense when all 
clients share an LAVC. Most of the files will be on an MSCP-served 
disk on the boot member. In addition, RSM can access disks that are 
local to RSM client members. 

The second key function is a way of automating the software dis- 
tribution process. These functions do not require clients to be on the 
same Ethernet as the server. Often, a software update requires an 
update on the configuration of several RSM client members. RSM al- 
lows clients and software to be put into groups. Each group accesses a 
common subset of software files, and other configuration information. 
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Files that may be automatically distributed include system informa- 
tion as well as commercial software. For example, every time a new 
node enters the network, in Phase IV it is necessary to update every 
other node’s session control database. RSM can be used to perform 
that task for each of the client nodes. 

A final function of RSM is the ability to create central print queues 
and then authorize access to the queues by client groups. This func- 
tion is complementary with the Distributed Queuing Service (DQS) 
discussed in Chapter 3. 


Terminal Server Manager/VMS 


This is the third place that discusses terminal severs. The basic over- 
view of the LAT architecture was in Chapter 4. Use of the terminal 
server was discussed in the Chapter 6 on local area networks. 

Terminal service management can be done with a locally attached 
terminal or using the Terminal Server Manager/VMS software. Since 
a local terminal can be used, it is also possible to use the remote car- 
rier console capabilities of the MOP protocols from the NCP user in- 
terface. The NCP interface lets a user connect to the terminal server, 
then type a CTRL/D to disconnect from that port. 

The Terminal Server Manager/VMS offers several additional fea- 
tures over a local terminal or the use of NCP and the MOP remote 
carrier console capabilities. The software allows domains to be defined 
consisting of multiple terminal servers. A particular operation can be 
applied to the entire domain. 

With domains, wild card operations can be performed. For example, 
the user could specify that port 1 on all terminal servers be changed to 
9.6 kbps. With NCP, this would have to consist of several different 
operations, possibly driven by a batch file. Another advantage of the 
Terminal Server Manager/VMS is that a remote test can be initiated 
on a terminal server to determine if it is operational. 

A management directory allows all terminal servers to be given 
ASCII names. The software can also set up domains of terminal ser- 
vers. Domains are useful for group operations. In addition to con- 
figuring the remote, local, or dynamic characteristic of a port, the 
manager is able to set many other characteristics. Speed, character 
size, parity, and terminal type are just of some of the many and 
wonderfully varied parameters. Figures 8-8 and 8-9 show some ter- 
minal server characteristics. 

This software can perform operations on both permanent and 
volatile parameters on remote terminal servers by name. For the 
DECServer 100 and 200, permanent parameters are stored in non- 
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volatile random access memory (NVRAM). For the DECServer 500 
and the Ethernet terminal server, permanent information is instead 
stored on a Phase IV host which then downline loads an image at 
initialization time. 


Remote Bridge Management Software 


Bridges are fairly self-sufficient, given the automatic nature of the in- 
itialization, the deterministic spanning tree algorithm, and the auto- 
matic learning algorithms. The RBMS software is used to control fil- 
tering on a bridge, to test availability, and to disable a port on the 
bridge as a way of isolating one Ethernet. 

To simplify management, each bridge is given an ASCII name which 
corresponds to a physical address. The RBMS manager can then in- 
voke a self-test on a particular bridge by name. It is also possible to 
display a variety of different statistics, such as the status of the for- 
warding database or the current values of traffic counters. Figures 
8-10 and 8-11 show some bridge characteristics. 

The software allows multiple users to access a single bridge. While 
this is technically feasible, it is an unusual network manager that 
would want to have several people simultaneously working on a single 
bridge. The multiuser interface is useful for multiple data collection 
activities. 

Since bridges are an operational node on the Ethernet, there is real- 
ly no reason that the bridge should have a separate management in- 
terface from, say, a terminal server or a VAX. The Phase V manage- 
ment architecture has the hooks necessary to include these types of 
devices into the broader DNA management structure. This level of 
integration allows a single user interface to manage a variety of dif- 
ferent related devices. 


NMCC/EtherNIM 


The NMCC software is an interface to two sources of information. The 
DECnet Monitor portion of NMCC provides a graphic interface to Net- 
work Management Listeners and thus provides an alternative to NCP. 
The Ethernet Network Integrity Monitor (ETHERnim) provides an in- 
terface to the Ethernet subnetwork and thus replaces some of the 
function of the LAN Traffic Monitor. 

ETHERnim provides a graphic representation of network status. 
Since multiport transceivers and all repeaters are transparent to the 
network, the software allows the user to manually construct a topology 
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Local> show port 


Port 48: “E 


Character Size: 
Flow Control: 
Parity: 


Access: 
Backward Switch: 
Break: 

Forward Switch: 


Preferred Service: 


Authorized Groups: 
(Current) Groups: 


8 
XON 
None 


Local 
None 
Local 
None 


None 


80-81 
86-81 


Input Speed: 9608 Bee 
Output Speed: 9688 Ba 
Modem Control: Disabled 


Local Switch: None BB 
Name: LC-3-16 Be 
Session Limit: 4 Bas: 
Type: SOFT 


Enabled Characteristics: 


Autobaud, Autoprompt, Broadcast, Loss Notification, Message Codes 


NNN NNN eee aa aaa! 


Courtesy of Digital Equipment Corporation 


Fig. 8-8 Terminal server port characteristics. 
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Local> show server 


DECserver 500 V1.0 LAT VS.1 ROM V1.8.2 Uptime: 45 16:37: 


Address: 68-@0-ZB-@8-16-BA Name: zk33cZ Number: Z 


Identification: 


Circuit Timer: Passuord Limit: 


Inactivity Timer: 


Keepalive Timer: 
Multicast Timer: 
Node Limit: 


Service Groups: None 
Backup Hosts: None 


Enabled Characteristics: 


Queue Limit: 
Retransmit Limit: 
Session Limit: 


Courtesy of Digital Equipment Corporation 


Fig. 8-9 Terminal server characteristics. 
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Bridge Characteristics Display Example 


Bridge Characteristics as of Z2@-Feb-85 12:13:25 
Bridge LANZtoLANS, Address AA-BB—-BG-12-34-11 


Bridge id: (Cpriority/address) 128/AA-0G-06-12-34-11 
Bridge type: 

Firmware version: 

Forwarding entries — max volatile: 

Forwarding entries — max non-volatile: 117 

Total data line entries: 

Current highest line number: 


Courtesy of Digital Equipment Corporation 


Fig. 8-10 RBMS screen of bridge characteristics. 


Known Forwarding Physical Entries as of 2@-Feb-85 12:35:55 
Bridge LANZtoLANS, Address AA-BG-BB-12-34-11 


Physical Address Outbound Last Seen Destination Set by Auto- 
Line On Line Delete 


88-88-Z2B-Z2Z2-8B-88 NONE N/A NONE SELF NO 


- AA-@B-8B-12-34-11 NONE N/A NORMAL SELF NO 
AA-GB-BB-8B-12-34 Line 2 Line Z NORMAL MANAGEMENT NO 
AA-GB-6B-86-12-33 NONE Line Z ACTIVE LINES MANAGEMENT NO 
AA-GB-BB-BB—-12-22 Line 1 N/A NORMAL LEARNING YES 
08-@80-3B-Z22-00-01 NONE NONE NONE MANAGEMENT NO 


Courtesy of Digital Equipment Corporation 


Fig. 8-11 Bridge forwarding database. 


that includes the different segments. Otherwise, the Ethernet is con- 
sidered to be a logical bus. 

Because ETHERnim operates at the Ethernet level, it is able to 
work with all devices on the Ethernet regardless of their protocols. 
The topology can thus include non-DEC devices, and the monitoring 
commands and statistics can include non-DEC protocols. The refer- 
ence database in NMCC allows information on all devices to be sup- 
plemented with data such as the physical location of the device or the 
person responsible for it. 

Various types of summary data can be examined. The top talkers 
and listeners on the network can be shown. Data can also be sorted 
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by protocol type. Finally, the top pairs of nodes that communicate 
with each other can be displayed. 

In addition to providing summary information on network status, 
ETHERnim is able to provide testing of nodes to various levels in the 
protocol stack. If the remote node is running VMS, the software can 
perform loopback tests all the way up to the user level. This confirms 
that all of the different layers of the network necessary for user to 
user communication are functioning properly. 


LAN Traffic Monitor 


LAN Traffic Monitor is a combination of a LAN Bridge 100 and some 
special software that is downloaded to change it from a store-and-for- 
ward device into an observation device. This software is known as the 
LTM Listener and is stored on a Phase IV host and then downloaded. 

The LTM Listener periodically sends out datagrams. Those LTM 
datagrams are received on all VAXs that have the LTM user interface. 
This software collects the datagrams and summarizes them. 

The software is able to summarize the data from the LTM listener 
and provide information on current, long-term, and peak usage. This 
information can be presented as a function of protocol types, nodes on 
the Ethernet, or packet size. The LTM Listener can display a histori- 
cal graph of use for up to 48 hours. 

One useful feature is the ability to display the top 10 talkers on the 
network. When users notice a slowdown in service, one of the first 
place to look is to see if some outrageous file transfer is in progress 
and has caused Ethernet saturation. Often nicknamed as a 
LOUD$MOUTH command, this accompanies the PIGS command which 
display the top CPU users on a particular node. Network managers 
are not always known for their tact. 


PBX/Facilities Management 


PBX/Facilities Management (P/FM) provides a management and ac- 
counting interface to selected PBX systems. Not surprisingly since 
DEC owns several, there is an interface to the Northern Telecom SL-1 
family. There are also interfaces to the AT&T Dimension and System 
85 PBX systems. 

The software allows a user to track calls and produce billing reports. 
The billing reports are produced at the conclusion of each call and can 
thus be used for chargeback systems, such as those used in hotels. 
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Call billing is based on standard rate tables. Charge estimates are 
constructed based on the mileage bands, country codes, and other nor- 
mal indicators for long-distance communication charges. In addition, 
bills can include allocated costs such as facilities rental. 

As a management tool, the software is able to examine blocked or 
queued calls as a method of assessing capacity. In addition, calls can 
be directed by cost or duration or by specific lines. An online directory 
facility is included. 


Phase V Network Management 


Network management in Phase V has many similar functions to Phase 
IV, but the architectures have been generalized to support a more 
heterogenous environment with different types of management inter- 
faces. The main functions in the network management modules in- 
clude several important features. 

First, the network management function gives the user the ability to 
configure parameters or fine-tune parameters that have been automat- 
ically configured. The user is also able to monitor performance and 
log relevant data automatically in various kinds of sinks. The net- 
work management functions also provide the manager with warnings 
for failures of network components. Finally, the user is able to start 
up and shut down components. 

There are two main types of objects in the Phase V network 
management model. Entities are things that are managed. A node is 
an entity, as is the occurrence of a DDCMP data link module on that 
node. The director is the program that controls entities. Every entity 
on the network is required to provide an agent that interacts with the 
directors. This is in addition to the normal function of that entity 
which is to provide services to other entities. Figures 8-12 and 8-13 
show the structure of the Phase V network management model. 

Directors are the set of processes and commands that are used to 
provide the control. The interface to a director can be either an inter- 
active user, using a user interface program, or a program that auto- 
matically provides network management. Management in a DECnet 
can be either centralized or distributed—each provider of the network 
management function interacts with a director. 

Each entity in the network consists of a unique name and a series of 
attributes or events. An attribute is a piece of information that the 
entity maintains, while an event is a state transition that occurs at a 
particular time. An event might be a log-in failure. An attribute 
could be a count of log-in failures that occurredafter a particular time. 
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Fig. 8-12 Phase V management structure. 


Entity names are unique within the network. The top level com- 
ponent of the namespace is a node, which has a unique name. Each 
node has a series of modules that have unique names, such as the 
routing module, the DDCMP module or the OSI transport layer 
module. Each module may then have a series of subentities. The 
DDCMP module would have a subentity for each data link that is 
currently defined. 

The information an entity can maintain is quite varied. Each entity 
has a unique ID. It also has a series of entity specific characteristics 
such as the polling rate for a DDCMP multipoint link. Entities also 
have a series of status attributes which change dynamically without 
intervention. An example of this would be a change in the link state 
of a DDCMP link. 

Another type of attribute is a series of counters. These counters are 
used for error management, billing, and performance tuning. Each 
entity in DNA has a series of counters defined. There may also be 
counters specified for events that are marginally related to the net- 
work, such as distributed naming service name changes. 

Phase IV network management consists of a Network Information 
and Control Exchange (NICE) Protocol. This protocol is being 
replaced by the Common Management Information Protocol (CMIP). 
CMIP has two subprotocols: 
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| ENTITY 
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Fig. 8-13 Phase V event dispatching. 


» MICE is the Management Information Control and Exchange 
protocol which replaces the previous NICE protocol with an equally 
cute name. 

a The Management Event Notification (MEN) has been added to ex- 
plicitly deal with the problem of passing events around the network. 


In Phase V, there may be an arbitrary number of sinks for events. 
The MEN protocol is used to communicate between the source of the 
event and the sink node. Each node on the network provides an event 
dispatcher. This dispatcher is able to accept events from a variety of 
events on that node. The dispatcher provides both a buffer for events 
and the ability to filter particular streams of events to different sinks. 

A significant change in Phase V is the replacement of the venerable 
Network Control Program (NCP) with a series of more modern inter- 
faces. The command language interface replacement is the network 
control language, which also can issue NCP commands for manage- 
ment of Phase IV environments. 

The network control language receives input directions from a ter- 
minal. These are then translated into directer commands. The direc- 
ter then uses the MICE protocol to notify the relevant entities. A 
significant improvement in NCL is the ability to use a wild card in 
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entity specifications. This would allow a single command to affect all 
lines in a particular DDCMP module or all nodes on a network. The 
NCL also allows interaction with a DNS nameserver to register node 
names. 


EMA: Phase V user interface architecture 


Accompanying many of the Phase V management advances is a new 
architecture for the structure of network management user interfaces. 
This architecture, called the Enterprise Management Architecture 
(EMA), is meant to handle the problem of directing a complex 
heterogeneous network. 

EMA consists of a management information repository that is 
similar to the NMCC management database. This is managed by an 
EMA executive, similar to the NMCC kernel. This kernel presents a 
common interface to all users of the management tool. Figure 8-14 
shows the structure of EMA. 

In NMCC, the NICE protocols were the only method of accessing 
information and adding it to the kernel. EMA moves beyond that by 
defining a series of access modules. These access modules can access 
Phase IV networks using the NICE protocols. Another access module 
is able to access Phase V networks using the CMIP protocols. Yet 
other protocols can be designed to manage terminal servers, bridges, 
or any other entity on the network. 

A particular protocol family, such as NICE is able to manage a wide 
variety of different entities. In the DNA/NICE protocol family, 
DDCMP or routing modules are two of the different types of entities 
that can be managed. 

All entities are registered in the EMA Management Information 
Repository (MIR) when an access module is assigned. This entity 
class data defines the management functions available for a particular 
entity. If the entity is a television set, for example, the ON/OFF 
management function would be defined for that entity. When the 
management database sends down an ON command to an access 
module, it is the responsibility of the access module to form a valid ON 
message using the protocol for television sets. 

Once a series of access modules has been defined and the entity 
class data loaded into the database, there needs to be a way to ac- 
tivate those functions. Functional modules are used to activate ac- 
tions on the entities. Because a functional module is separated from 
the access modules, it is possible to have one functional module per- 
form a single operation on many different kinds of entities. For ex- 
ample, in the television example, a functional command might be to 
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Fig. 8-14 Modular user interface architecture. 


turn off all electrical appliances. It would the responsibility of the 
television access module to formulate a TELEVISION OFF command and 
the responsibility of the lighting control access module to broadcast a 
LIGHTS OFF command. 

Functions for an entity can be grouped into five classes, correspond- 
ing to the five categories used to classify CMIP data in the OSI net- 
work management model: 


s Configuration is used to set the original permanent characteristics 
of a network. 

a Fault management is used to cure fault conditions, such as switch- 
ing to a backup line in the case of circuit failure. 

a Performance management is used to control overall performance, 
such as adjusting window sizes to optimize a transport layer 
module for a particular transmission media such as satellite. 

s» Accounting management is used to collect data on usage. 

a Security management controls access to the network. 


Each of the functions can be incorporated in a set of functional 
modules that interface to the executive just as access modules do. If 
entities all share common classes of entity data, such as an ON/OFF 
command, a single functional command is able to work on all the dif- 
ferent types of accesses required. 
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Functional models are not necessarily limited to the five OSI clas- 
ses. A functional module might be used to periodically generate 
reports on the behalf of users or to form topological maps based on 
entity locations. 

By keeping functional tasks in separate modules, the network 
management capabilities can grow gracefully. Questions of perfor- 
mance and fault management, for example, can start with a very 
simple manual capability of switching to alternate lines. That module 
can slowly grow to‘incorporate automatic switching or artificial intel- 
ligence-based decision making. 

The presentation of information on the screen is the responsibility of 
a third set of modules, called presentation modules. One presentation 
module can be used to display information on a VT100 terminal, while 
a second could handle the DECwindows environment of bit-mapped 
screens. Users could write custom presentation modules for other 
equipment, such as 3270 terminals. 

Many of the functions that were present in NMCC are also present 
in the new architecture. Instead of fixing the functionality of the sys- 
tem and limiting protocols to NICE, the new structure allows a 
modular approach to network management. It would even be possible 
to manage an IBM network from this product by defining a set of 
NETVIEW access modules. 

What makes the architecture important is that it is not limited just 
to network management. A database management task can define a 
series of functions, such as BACKUP DATABASE. An SQL-based access 
module can then be defined and the database management functions 
can be integrated into the same user interface as the network manage- 
ment. Similar access modules could be defined to manage the VMS 
operating system. 

Just because a common tool is used to manage different environ- 
ments does not mean that the same person will perform both tasks. 
EMA allows entities to be grouped into domains. Access to domains 
can then be limited by class of user. 

It is possible for a single entity to be part of multiple domains. This 
allows entities to be available to multiple groups of users. For ex- 
ample, both the data and the voice manager may need the ability to 
allocate bandwidth from an application-independent backbone. Both 
managers, in this case, would need the ability to control bandwidth 
allocation through T1 switches. Needless to say, abuse of this multi- 
ple access can easily lead to a policy change to put the Tl switches 
into a separate, singly managed domain. 
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Summary 


This chapter began with a discussion of the implementation of DNA 
on various operating systems. DNA is a flexible architecture which 
permits the same functionality to be implemented in a wide range of 
operating systems. While VMS still provides the highest level of 
functionality, even DOS systems are able to participate in a DECnet 
as a full-featured end node. 

Managing the network is potentially a very complex task. Phase IV 
networks are managed using the NMCC and NCP user interfaces. 
Other user interfaces are used to manage multiple VAXs, terminal 
servers, bridges, PBXs, and other components of a distributed network 
environment. 

Phase V of DECnet provides several valuable additions to network 
management capabilities. First, the DECnet protocols have been ex- 
panded to be more flexible and more powerful. More importantly, 
DEC has developed the EMA architecture which permits a single user 
interface to manage a wide variety of components. These components 
can be Phase IV or Phase V entities but can also include other net- 
work and nonnetwork components. 
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Chapter 


TCP/IP and the Network File 
system 


Overview of This Chapter 


This chapter discusses the TCP/IP networking protocols which are an 
alternative to the Digital Network Architecture and other DEC- 
developed networking schemes. One of the features of TCP/IP is that 
it is a nonproprietary set of networking standards. Because of the 
open nature of the protocols and the adoption of TCP/IP in the Unix 
marketplace, a wide variety of vendors support TCP/IP implementa- 
tions, including DEC on both the VMS and Ultrix operating systems. 

The basic TCP/IP protocol suite was sponsored by the Defense Ad- 
vanced Research Projects Agency (DARPA) for use in Arpanet. The 
Arpanet is a wide area network that connects different research 
groups and contractors involved in defense contracting. Although Ar- 
panet has been supplanted by more modern networks, the TCP/IP 
protocols continue to be used. 

TCP/IP provide layers 3 and 4 of the ISO protocol stack. The Inter- 
net protocols provide routing among networks and in some cases 
within a particular network. The Transmission Control Protocol 
(TCP) and the User Datagram Protocol (UDP) take data delivered by 
IP to the appropriate node and send it up to various upper-level 
protocol users. 

The original TCP/IP protocols offer only a limited amount of net- 
work functionality. Built on top of TCP/IP are three applications built 


241 


242 DEC Networks and Architectures 


directly on the transport layer that provide file transfer, mail transfer, 
and a virtual terminal service. 

TCP/IP has been supplemented by the Network File System, 
developed by Sun Microsystems. Sun started out by adding session 
(RPC) and presentation (XDR) layers to the TCP/IP model and then 
providing a variety of layer 7 services. 

The basic NFS service is a distributed file system. This allows files 
from one computer to be remotely mounted on another computer. The 
NFS client sees a series of files as though they were local. The files 
actually are a combination of local files and remotely files from a 
variety of NFS servers. This allows diskless nodes to remotely mount 
an operating system. Another use of NFS is to allow a user to 
remotely mount their files no matter which machine on the network 
they log into. This means that users can use a variety of different 
computers and always see a common file space. 


Overview of IP 


Internet protocols are used for delivering data between different net- 
works in addition to within one centrally administered system. This is 
done by connecting groups of autonomous systems, or networks. Each 
of these networks is connected with a gateway. 

The Internet protocols only define how subnetworks or data links 
are connected together. A subnet might be X.25 or Ethernet or ISDN. 
The subnet provides a virtual link between any two nodes in the sub- 
net. 

IP defines how packets are forwarded from one subnet to the next. 
This forwarding process is aided by the presence of routing update 
messages that keep forwarding databases up to date. Several different 
types of update messages are used, depending on the collection of sub- 
nets involved in a management domain. 

A related set of services are the domain nameservers. These 
nameservers are able to translate logical names into internet addres- 
ses. While not a part of IP, the nameservers are an important supple- 
ment. 

The Internet protocols are especially important because they form 
the basis of the connectionless network service of the Open Systems 
Interconnect model. The IP is very similar to the level 2 routing in 
between DNA areas, and some of the original work on IP was done at 
DEC. DEC will use the IP protocols in Phase V of DECnet as a 
method of routing data between DECnet areas and between DECnet 
and non-DECnet administrative domains. 
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Internet Addresses 


The Internet addresses are administered by the Network Information 
Center (NIC) located at the Stanford Research Institute (SRI). Ifa 
locally administered Internet system is not connected to the larger In- 
ternet, the address can be arbitrary. However, when the network 
manager wants to connect to other IP based systems, such as the Ar- 
panet, all local addresses have to be reassigned. 

An IP address is a 32-bit number. Usually, each octet of the ad- 
dress is represented by its decimal equivalent. Thus, an Internet ad- 
dress of all 1s would be represented as: 


256.256.256.256 


There are three classes of Internet addresses assigned by SRI. If bit 
1 is set to 0, this is a class A address, reserved for a very few large 
networks such as the Arpanet. Class As have the next 7 bits as the 
network ID, leaving the remaining 24 bits as a host ID. Class A net- 
works are reserved with networks with more than Des or 65,636 hosts. 

If the first bit of the address is set to 1, the IP address is a class B 
or class C address. Class B addresses have bit 1 set to 1, bit 2 set to 
0, and 14 bits for a network ID. The remaining 16 bits are for the 
host ID, allowing networks of 256 to 65,000 nodes. Class C networks 
have a 22 bit network ID and are used with networks with fewer than 
256 hosts. 

An Internet address represents a connection to the network. It is 
important to understand that a gateway is connected to two different 
networks and would thus have addresses on both those networks. 
There is also a broadcast address with all bits set to 1. Broadcasts are 
received by every host on that network, but they are not rebroadcast 
by gateways onto other networks. 


Address Resolution 


Internet addresses are conceptual addresses assigned by a network 
administrator. When an IP node wishes to transmit information to 
another IP node, the IP module dispatches the data to the data link 
layer. The data link layer sends it across to another data link layer 
node on that network. In order to send the IP packet, the IP address 
must be translated into a physical address for that particular trans- 
mission medium. 

Internet protocols can be implemented over a wide variety of data 
link mechanisms. In each case, the data link layer makes all other 
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Fig. 9-1 An Address Resolution Protocol frame. 


nodes on that particular network appear to be one hop away. Ether- 
net does this using a bus topology and the CSMA/CD protocols, possib- 
ly with bridges to form an extended Ethernet. 

A token ring also makes all other nodes appear one hop away, 
through the mechanism of passing a token. Finally, X.25 can also be 
used as a subnetwork. X.25 allows the creation of switched or per- 
manent virtual circuits. These circuits allow the IP layer to assume 
that it is directly connected to the host to which it wishes to talk. 

In order to map Internet addresses into physical addresses of “ad- 
jacent” nodes, the Internet uses an Address Resolution Protocol (ARP). 
An ARP packet is a special type of broadcast. On the Ethernet, ARP 
packets are a special packet type, just as IP or LAT or the DNA Rout- 
ing Protocol have their own packet types. Figure 9-1 shows an ARP 
packet on the Ethernet. 

When a node broadcasts an ARP request, the node also includes its 
own Internet to physical mapping. Since each node contains a small 
cache, this minimizes the number of ARP requests broadcast on the 
network. 

One of the Internet design philosophies is to minimize the locality of 
broadcast requests. If an ARP request was rebroadcast by gateways, 
this could lead to a tremendous drain on network resources. 

The reverse of the Address Resolution Protocol is the Reverse Ad- 
dress Resolution Protocol or RARP. RARP requests are sent by disk- 
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Fig. 9-2 Contents of an Internet packet on Ethernet. 


less nodes to determine their Internet address. Usually, that address 
is not stored in the ROM of the diskless node, but the RARP protocols 
are. 


IP Packets 


The IP protocol offers a connectionless datagram service to deliver 
data. This means that the service provider sends information one 
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packet at a time. Each packet may or may not get there. Different 
packets may travel over different routes. Assured delivery, if needed, 
is provided by the Transmission Control Protocol. Figure 9-2 shows 
an Internet Protocol packet on the Ethernet. 

A packet of information from either an IP control module or an 
upper-layer user of IP is enclosed within an IP header. The IP 
datagram is then encapsulated with a subnetwork header, such as 
Ethernet information. IP is able to take a datagram and segment it 
into smaller pieces for the data link layer. A design constraint sug- 
gested by IP architects is that a data link layer should be capable of 
handling 576 octets without segmentation. Once an IP datagram is 
segmented, it usually stays segmented until it reaches it’s final des- 
tination. This occurs even if subsequent data link layers are able to 
accommodate larger packet sizes. The IP packet format is as follows: 


IP version 

IP length 

Type of service 

Total length 
Fragmentation control fields 
Time to live 

High level protocol type 
Header checksum 

IP source address 

IP destination address 
Option class and number 
Padding 

Data 


The IP header provides a variety of information in addition to the 
source and destination addresses. The header begins with the IP ver- 
sion number and the length of the header. The type of service indi- 
cates both the service type and the precedence of the data. Precedence 
is an indicator of delivery priority, ranging from 0 for normal data to 7 
for network management data. Service type gives the user a choice of 
low delay, high throughput, and/or high reliability. Service type can 
be thought of as a “hint” to routers. High-throughput data might be 
routed via a satellite, while a low-delay flag might use a low-capacity 
9.6-kbps unused line. 

Fragmentation fields indicate how to segment and desegment IP 
messages. A flag can be set in this field indicating that the data 
should not be fragmented. Another flag indicates if there are more 
fragments of a message to be sent. An identification field is a unique 
ID for that message. All fragments of a message contain the same ID 
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field. Finally, the fragmentation offset indicates where in the message 
this particular fragment is contained. 

The TIME TO LIVE field is a number which says how long this par- 
ticular packet can survive on the network. Each host or gateway that 
receives this packet decrements the number by 1. If a gateway 
receives a packet with a time to live of zero, it performs a summary 
execution. 

Option classes determine if the data is normal data or is used for 
debugging. Within an option class, there are a variety of option num- 
bers. An option class of 0 stands for either a datagram or a network 
control packet. A number 9 within class 0 indicates that strict source 
routing, as specified by the source host, must be used. If that route is 
not available, the gateway should not choose an alternate route. 

A number of 7 within class 0 specifies that routes should be traced. 
Every gateway that is visited has its address stamped in the packet. 
Option class 2 (debugging) has an option number of 4, which time 
stamps all stops the packet made on the way. This allows measure- 
ment of network performance. 


IP Routing 


There are two types of routing within an Internet. Within a single 
network, the IP module need only map the IP to the physical address 
and send the packet. This, of course, implies that the subnetwork, 
such as X.25, is able to shield the complexities of the underlying data 
link from the IP module. Subnet routing, discussed later, allows IP to 
control routing at the subnetwork layer. 

Another IP routing scenario is to route a packet to another network. 
This is done by consulting an Internet routing table. This table con- 
tains a series of pairs of information showing the destination net and 
the nearest gateway that can access that network. ‘The host then 
routes the packet to the designated gateway. That gateway, in turn, 
will consult its routing table for the next gateway. Finally, the data 
will be delivered to the destination network gateway, which will 
deliver the packet to the designated host. 

An important IP concept is that routing decisions are made on the 
basis of networks, not by the address of a destination host. A par- 
ticular destination host is a part of a network, which is accessible by a 
gateway. A more sophisticated analysis of the location of the host 
within the target network is not available from the sending node. If 
we specify the address of a remote host that doesn’t exist, an error 
message will not be generated until the gateway connected to that 
network is reached. 
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Since there is no concept of relative costs available in a routing 
table, there is no capability to do load balancing across multiple paths 
to a destination host. IP is also not able to segment traffic by type of 
traffic (i.e., priority) over different data links. One option available is 
source-specified routing, in which the source node specifies the exact 
path to take, alleviating the gateways of the responsibility for deter- 
mining the optimal path. 

Two mechanisms will be examined that supplement the relatively 
unsophisticated routing decision process in IP. Internet control mes- 
sages are used to allow different IP modules to communicate among 
each other, and include a REDIRECT DATA request which indicates 
that data should really be sent to another gateway on the source net- 
work that has a better path to the destination host or network. The 
second mechanism is routing control messages, which allow gateways 
to communicate among themselves and provide more sophisticated 
path information. 


Internet Control Message Protocol 


The Internet Control Message Protocol (ICMP) is used by IP to trans- 
mit IP error and control messages. ICMP messages are exchanged 
between different IP modules. A simple message is the ICMP ECHO 
REQUEST message, which is used to test whether a destination is 
reachable. This echo request message can also be used to specify 
average delay on a line by timing the amount of time it takes to get a 
reply. Figure 9-3 shows an ICMP packet. 

Unreachable destination request messages are sent by gateways 
when they receive a packet they are unable to forward. The reports 
sent by the gateway could indicate that the network or host is un- 
reachable or that a particular upper-layer protocol or port is unreach- 
able. If the source host indicated that fragmentation was not allowed, 
the gateway might also send a report if it would have needed to frag- 
ment the data. Finally, a report can be sent if the source specified 
routing failed. 

Unreachable destination reports also include the beginning of the 
packet data that was originally sent so the source can determine 
whom to notify about the failure to successfully send the data. A vir- 
tual terminal service might use the Transmission Control Protocol, 
which in turn would use the IP protocols. If, for some reason, the des- 
tination is unreachable, the IP module would want to notify the TCP 
module. The TCP module, in turn, would notify the TELNET virtual 
terminal service. TELNET would then print a message on the screen 
to the user. 
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Fig. 9-3 An ICMP packet. 


A second type of ICMP message is known as a SOURCE QUENCH 
message. If a host receives more packets than it can handle at the IP 
layer, it does two things. First, it throws away all the packets, typi- 
cally in the form of a buffer overflow. Second, the IP module issues a 
source-quench message which instructs the sending module to reduce 
the sending rate. 

Source-quench messages only operate for a small period of time. 
The recipient of a source quench message reduces the transmission 
rate for a period of time. Each time a new source quench message is 
received, it reduces the transmission rate again. If no more messages 
are received, the sending module gradually increases its sending rate 
back to the original. 

The third type of ICMP messages are ROUTING CHANGE REQUESTS. 
A redirect data request is sent by a gateway when it determines that 
it is not the optimal gateway for a particular destination. The mes- 
sage to the originating host is not broadcast to the network. The mes- 
sage can instruct the host to redirect all datagrams to that destination 
host to the destination network. The redirect message can also specify 
that certain types of services be redirected. 

A long route notification is sent when a gateway receives a packet 
with a time to live flag that is about to expire. When the IP module 
destroys the offending packet, it also sends a message back to the 
sending host. This is sort of like a telegram sent by the military to 
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Fig. 9-4 Time stamp sequence. 


widows of war victims (“We are sorry to inform you that your packet 
number ... has expired in the line of duty”). 

The fourth type of ICMP message is time stamp requests and 
replies. These messages are used to estimate average delay on the 
network. Average delay is used to determine the transmission rate to 
use. Several other timers may also be influenced by average delay. 
For example, when the beginning fragment of a message is received, a 
timer is started by the IP module. If all fragments have not been 
received before the timer occurs, an ICMP FRAGMENTATION REAS.- 
SEMBLY ERROR message is sent. 

To estimate round trip delay, four time stamps are involved (see 
Figure 9-4). The sender time stamps the request packet. The 
recipient stamps the packet when it receives it and when it sends back 
the reply. The original sender time stamps the reply when it receives 
it. Time stamps 2 and 3 provide an estimate of how long it took the 
target to process the information. Time stamps 1 and 4 provide the 
total amount of time on the network. By subtracting the two delay 
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estimates, one can arrive at a delay for the data link. Repeating the 
sequence several times yields an average delay parameter. 


Autonomous Systems and the Internet 


The Internet is composed of a series of autonomous systems. An 
autonomous system is a centrally administered network. For example, 
the Arpanet is an autonomous system. Each autonomous system of- 
fers a series of gateways which are used to connect to other 
autonomous systems. Note that an autonomous system can be com- 
posed of several networks. 

A series of core gateways provides the glue that holds all these dif- 
ferent networks together to form the Internet. The core gateways are 
centrally administered and provide a reliable backbone for the Inter- 
net and are administered by the Internet Network Operations Center. 

The core uses the services of both Arpanet and the National Science 
Foundation’s NSFnet to provide a high-capacity link among core 
gateways. Core gateways are then connected to a variety of 
autonomous systems. The gateways on these autonomous systems 
communicate with each other and the core using an Exterior Gateway 
Protocol (EGP). Figure 9-5 illustrates this concept of autonomous sys- 
tems and routing update protocols. 

The EGP is used by neighboring gateways. It allows a gateway to 
acquire (register) a neighbor. Note that the term “neighbor” is mis- 
leading; it only implies that the underlying data link, such as X.25, 
shields the actual location of the node. Note also that gateways don’t 
arbitrarily select neighbor gateways. This is an administrative 
decision by the network manager. 

EGP has two kinds of operational messages. First, gateways peri- 
odically test to see if the neighbor is reachable. In the acquisition 
process, the nodes agree on the interval of these HELLO messages. 
Presumably, this message will be sent fairly frequently. 

A HELLO message must be acknowledged. Even if an ACK is not 
received, the sending gateway does not immediately assume that the 
target is not operational. This is important because there is a great 
deal of overhead involved in a disabled gateway. If several packets 
are unacknowledged, the host is declared to be dead. Before the host 
is considered back up again, it must successfully acknowledge several, 
not just one, HELLO messages. 

The second type of message is a routing update message, which will 
be sent less frequently than the HELLO message. A routing update 
message is sent in response to a poll request or because of a change in 
the network configuration. The EGP allows a gateway to advertise 
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the availability of networks only within its own autonomous system. 
This allows each autonomous system to maintain full control over how 
it advertises availability. 


Interior gateway protocols 


Within an autonomous system there may be several gateways since 
there may be several networks. The gateways within an autonomous 
system communicate with each other using an interior gateway 
protocols. There are several interior gateway protocols available, in- 
cluding the Routing Information Protocol (RIP). The core can also be 
considered to be an autonomous system and has its own interior 
protocol called the Gateway-to-Gateway Protocol (GGP). 

The GGP consists of a series of advertisements within the core. 
Each core gateway advertises which nets it can reach and the cost to 
reach that network. Cost is usually measured as hops, although the 
number can be artificially adjusted to take into account slow networks. 

The core gateways that use the GGP have a list of all possible 
routes to a destination network. The core thus provides alternative 
routing in case of routing failures. Also, by using the cost metric, they 
offer a form of least-cost routing. Note that the sending host must 
first send the data to a gateway, which then determines the optimal 
route. 

The Routing Information Protocol (RIP) is frequently used as an 
IGP, particularly within Unix implementations of the Internet 
Protocol. This is because the Berkeley versions of Unix have imple- 
mented RIP in a route daemon called routed. “Daemon” is a Unix 
term for a program that functions without user intervention. 

RIP is used between neighbors. Note that the EGP advertised the 
existence of all gateways it knew about. RIP is used only to broadcast 
destinations it can reach, not those reachable by other nodes. RIP 
advertises the existence of a network and the cost of reaching that 
network where cost is the number of hops to that network. Each RIP 
neighbor thus periodically transmits its routing table to its neighbors. 

An alternative to RIP is the HELLO protocol. Unlike RIP, HELLO 
uses delay as a metric for cost, not just the number of hops. HELLO 
is used as an interior gateway protocol within the NSFnet. Each node 
keeps an estimate of the roundtrip delay to various hosts it can reach. 
It then transmits that information, along with its own time stamp, as 
a HELLO packet to neighboring nodes. This allows the neighbor to 
keep an estimate of the time of its neighbors, and so on. 
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Subnet Routing 


Official Internet addresses fall within the three classes outlined ear- 
lier in the chapter. Within a network, there are no alternative paths 
because the IP assumes that it is one hop away from all nodes on the 
network. Subnets allow a network to be partitioned into a series of 
subnetworks, each connected by gateways. Thus, although the ex- 
terior gateway knows about only one gateway, that gateway can fur- 
ther transmit information to a series of subnet gateways. 

One technique for providing subnets is called the transparent 
gateway mechanism. Only a certain number of hosts are available on 
the Arpanet. Frequently a site has one officially connected host on the 
Arpanet but wishes to have other local hosts access the Arpanet also. 

The official host is the destination for all packets from the Arpanet. 
However, an Arpanet address only uses three of the octets in the ad- 
dress (See Figure 9-6). By adding bits in the unused portion of the 
Arpanet address, the target host can really be a network. 

Subnets are another mechanism. A class B network can have be- 
tween 256 and 16,535 hosts on the network. If a network has sig- 
nificantly fewer than 16,000 nodes, it can allocate a portion of the 
HOSTID field in the Internet address to be a subnetwork identification. 

When subnet routing is used, the routing tables are typically supple- 
mented with a subnet mask. The mask specifies which bits of the 
total Internet address should be considered as a specific network. A 
network mask of all 1s is really a way to identify a specific host. For 
other network masks, this specifies which gateway handles that par- 
ticular subnet. For true Internet routing, the subnet mask is set to 
the bits specified for that particular class of Internet address. See 
Figures 9-7 and 9-8 for an illustration of the two methods of providing 
access to routing within a network. 
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Fig. 9-6 Subdivisions of an ArPANET address. 
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Fig. 9-8 Using subnet routing tables. 
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In the routing table, a network mask of all 0s means that none of 
the network address should be considered. What this means is a 
default rule. If a particular address does not match, this is the 
gateway to use for all remaining addresses. 


The Domain Naming System 


The ARP protocols are used to translate Internet addresses into physi- 
cal addresses for a particular data link. One more level of translation 
is necessary for users of the network. This allows names to be formed 
that use alphanumeric characters and have semantic content, as op- 
posed to the 32-bit Internet number. 

Names in the Internet are formed in a hierarchy of domains. The 
name of a machine has the form: 


machine.suborganization.organization.domain 


Common domains include commercial (COM), educational (EDU), 
governmental (GOV), military (MIL), the Arpanet (ARPA), and foreign 
countries (the name of the country). 

Each level of the domain naming system has authority over the sub- 
domains it controls. Thus the COM domain can cede authority to the 
General Motors (GM) organization. GM, in turn, can cede authority to 
suborganizations, which finally have control over individual host 
names. 

Nameservers are used to map domain names into Internet addres- 
ses and are considered to be the authority within their subdomain. 
Nameservers form a hierarchy, finally reaching a root nameserver 
which is considered to be the authority for a root domain. 

Requests for translation of a name into an Internet address are sent 
to a nameserver. The server can either respond with the complete 
translation or with the name of another server to contact. In a recur- 
sive translation, the local server provides the interaction with the rest 
of the network. For nonrecursive translation, the client must then 
contact each of the servers. Figure 9-9 shows a DNS query on the 
Ethernet. 

Servers cache recently resolved names to reduce the amount of DNS 
traffic. If the server was not the authority for a translation, it is pos- 
sible that the cache is out of data. When a server gives out cache 
information for which it is not the authority, this is considered to be a 
nonauthoritative binding. The server then provides the address of the 
server that provided the initial binding of domain to Internet name 
translation. 


TCP/IP and the Network File System 257 


ID = 166 

Flags = 84 

Aus Conran Response 

Aacnbatie sot Beers authoritative answer 

See se Os not truncated 

Flags = 8X 

1... .... = recursion available 

Response code = OK (@) 

Question count = 1, Answer count = 39 

Authority count = @, Additional record count = @ 


Question section: 
Name sail.stanford.edu 
Type All records (*, 255) 
Class = Internet CIN,1) 
Answer section 1: 
Name = sail.stanford.edu 
Type = Host information CHINFO, 13) 
Class = Internet CIN,1) 
Time-to-live = 43200 (seconds) 
CPU = DEC-1880 
OS = WAITS 
Ansuer section 2: 
Name sail.stanford.edu 
Type Well-known service descriptor (WKS,11) 
Class = Internet CIN,1) 
Time-to-live = 43200 (seconds) 
Address = (10.0.@.11] 
Protocol TCP (6) 
Services Echo (7), Discard (9), Daytime (13), Quote (17) 
SMTP (25), Time (37), Finger (79), Supdup (95) 
Ansuer section 3: 
Name = sail.stanford.edu 
Type = Well-known service descriptor (WKS,11) 
Class = Internet CIN,1) 
Time-to-live = 43200 (seconds) 
Address = (180.0.6.11] 
Protocol = UDP (17) 


Ansver section 7 
Name = sail.stanford.edu 
Type = Host address (A,1) 
Class = Internet CIN,1) 
Time-to-live = 43200 (seconds) 
Address = (10.0.0.11] 
Answer section 8: 
Name = sail.stanford.edu 
Type = Mail transfer (MX,15) 
Class = Internet (CIN,1) 
Time-to-live = 43200 (seconds) 
Preference = 10 
Mail domain name = Sail.Stanford. EDU 
Answer section 9: 
Name = sail.stanford.edu 
Frame 48 of 97 
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Fig. 9-9 Domain name service query results. 
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One of the parameters on a DNS translation is a time to live 
parameter which specifies how long the translation should remain 
good. On static networks, this parameter is set very high. 

DNS queries can ask several questions within one packet. The 
domain nameservers are able to handle a variety of classes of names, 
not just Internet host addresses. Within the Internet class of DNS 
queries, there is also a provision for mail address translation as well 
as host translation. 

One frequent use of a DNS server is to provide an alias service. This 
allows the names of hosts to be abbreviated. The DNS server than 
provides the complete Internet translation. A user might send mail to 
joe(@pentagon which would then be translated into an address such 
as jmiller@host99876.Army.Pentagon.Mil 


Transport Layer Services 


There are two different options available for the transport layer in 
LGPL: 


= The User Datagram Protocol (UDP) is fairly efficient but offers a 
low level of service. 

sw The Transmission Control Protocol (TCP) offers assured delivery 
but at the price of more overhead. 


The User Datagram Protocol accepts data from the Internet modules 
that implement IP and forwards the data to different processes on the 
system. UDP adds to the network service by serving as a multiplexer 
for several application programs using one routing level module. Fig- 
ure 9-10 shows a UDP packet on the Ethernet. 

Each user of UDP is assigned a port number. Incoming data con- 
tains a 17 in the PROTOCOL TYPE field of the IP header. This signals 
the IP module that the data should be given to the UDP module in- 
stead of to some other user of the network service. 

The UDP header contains both a source and a destination port. 
Some ports are registered and can be found on many TCP/IP im- 
plementations. Some examples of well-known port numbers are: 


5 RJE Service 

7 Echo Service 

11 USERS—Show all users on remote system 
15 NETSTAT—Show network statistics 

17 Quote of the day service 

53 Domain name server 
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Source address = (36.53.8.18], Argus 
Destination address = (128.32.138. 4] 
No options 


---— UDP Header --—- 


Source port = 53 (Domain) 
Destination port = 53 (Domain) 
Length = 281 

Checksum = S33E4 (correct) 


resctetateretetatetctcPat 


g Sete ees aU aserareee 


{Normal end of “UDP Header'’.] 
---— Internet Domain Name Service header -—-- 


ID = 166 
Flags = 84 
oag cao Response 
Aa Wel authoritative answer 
not truncated 
Frame 91 of 97 
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Fig. 9-10 A UDP packet. 


69 Trivial file transfer protocol 


Many ports are registered to both the UDP and TCP transport ser- 
vices allowing users to access the upper-layer services from different 
transport layers. An implementation of the USERS command on an 
Ethernet might choose to use the UDP transport service because of 
the very low error rate on an Ethernet. A wide area implementation 
of the USERS command might choose to use TCP because of the pos- 
sibility of lost packets from leased phone lines or public X.25 net- 
works. 

In addition to well-known services with reserved port numbers, 
there are also port numbers available for transient use. These can be 
assigned by application programs at run time. Other port numbers 
are also available for registration by local users of the network as 
permanent services. 

In a UDP implementation, there is no assurance that data will ar- 
rive at the destination or that different packets of data will not travel 
by different routes and have their arrival order permuted. Because of 
this, UDP data must be self-describing. This means that the user of 
the UDP service must be able to interpret a message in a stand-alone 
context and determine what to do with it. 

The Network File System, discussed later, is a stateless application. 
This means no connection exists between the client and server and 
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every packet is self-describing. The NFS services are built on top of 
the UDP protocols which are a connectionless transport service. By 
contrast, DECs Distributed File Service is built on top of the connec- 
tion-oriented NSP transport layer of DECnet. 

TCP provides a more robust service by guaranteeing the delivery of 
data in the order received. This means that the application program 
can process data sequentially as a stream of bytes without regard for 
the mechanics of delivery of the data. The TCP protocols have been 
modified and enhanced in the TP4 transport service which is being 
used in Open Systems Interconnect (OSI) networking software. 

Like the NSP end-to-end communications protocols examined in the 
DNA chapters, TCP use a positive acknowledgment with retransmit 
(PAR) protocol. All data sent must be positively acknowledged or will 
be assumed lost. When a packet of data is sent, the sending TCP 
module begins a timer. If an ACK is not received before the timer 
expires, the data is retransmitted. 

It would not be very efficient to delay sending a second packet until 
the first packet has been acknowledged. TCP has a sliding window 
mechanism to provide higher throughput. The receiving module tells 
the originating TCP modules how many bytes of data it has received 
and how many more it is willing to receive. At any time, the sending 
module cannot have more than that number of unacknowledged bytes 
outstanding. | 

ACKs can be sent in their own packet or can by piggybacked on to 
data being sent back to the other module. Each time an ACK is sent, 
the TCP module also indicates the current size of the window. This 
allows the window to vary dynamically in response to network or host 
congestion. 

TCP modules are able to respond to congestion on the network by 
reducing their transmission time. The time-out parameter for data 
sent is a dynamic number that is a function of the average round-trip 
delay between two points on the network. As the delay increases, so 
does the time-out factor. As these delay times are increased, a well- 
designed TCP module should also reduce the transmission rate. This 
will alleviate the need for the target Internet module to send a 
SOURCE QUENCH ICMP message. 

Usually, the user of TCP allows the TCP module to decide how to 
packetize data. Normally, the TCP module will wait for a certain 
number of bytes to appear in a buffer before packetizing the data and 
delivering it to the IP module for transmission over the network. 

An upper-layer user can modify this behavior by issuing a PUSH 
DATA command. Thus, a user waiting for a response from a full- 
screen editor would not be forced to wait for a TCP timer to expire 
before having the data delivered to the target system. 
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Another option available to users of the TCP service is to label cer- 
tain data urgent. All data in the urgent buffer is delivered by TCP 
before data in the normal buffer. This is typically used by applica- 
tions programs for out-of-band signalling, such as an abort interrupt. 


Upper level TCP/IP services 


The basic TCP/IP model includes three simple types of applications. 
These applications use the transport layer directly rather than using 
the services of the presentation and session layers like other services 
examined in this book. The three basic applications include: 


a A file transfer protocol 
a A virtual terminal service 
s A simple mail transfer protocol 


DEC has furnished equipment and other support to the National 
Bureau of Standards in its effort to build gateways between these 
three basic services and their OSI counterparts. This allows a file to 
be transferred using FTAM up to the boundary of the OSI network 
and then transferred using FTP for the remainder of the path into the 
TCP/IP environment. 


File Transfer Protocol 


The File Transfer Protocol (FTP) is a program used for the bulk trans- 
fer of data from one node to another. The Berkeley Unix equivalent to 
the Arpanet FTP service is the rep (remote copy) command. In both 
cases, only entire files can be transferred, not selected records. Figure 
9-11 shows an example of an FTP session. 

Data in the FTP environment consists of a stream of data followed 
by an end of file marker. A more sophisticated interface allows data to 
be transmitted as records, with each record terminated by an end of 
record marker. 

FTP is supposed to transfer any type of data as long as it is com- 
posed of bytes and not arbitrary bit patterns. This poses a problem if 
the data transmitted has an occurrence of the bit pattern that is used 
to signify the end of record. To handle this and other signaling 
problems, FTP uses a byte with all bits set to identify a control se- 
quence such as the EOF mark. If the data actually consists of all 1s, 
the sending FTP module stuffs in an extra bit and the receiving 
module strips it. 
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eel ux1,1b1,gouz 

emg ux1.lbl.gou% ftp 

ftp> open ux3 

Connected to ux3,1b1.gov, 

228 ux3,1bl.gov FTP server (Version 4,7 Sun Sep 14 12:44:57 PDT 1986) ready, 
Name (ux3,1b1,gov:bob): bob 

Password (ux3,1b1,gov: bob): 

331 Password required for bob, 

238 User bob logged in. 

ftp> status 

Connected to ux3,1lbl,gov, 

Mode: stream; Type: ascii; Form: non-print; Structure: file 
Verbose: on; Bell: off; Prompting: on; Globbing: on 

Hash mark printing: off; Use of PORT cmds: on 

mal ftp> ls x, log 

#4 208 PORT command okay, 

158 Opening data connection for /bin/ls (128,3,254,19,133911) (@ bytes), 
irds, log 

226 Transfer complete, 

1@ bytes received in @,98 seconds (8,611 Kbytes/s) 

ftp> close 

221 Goodbye, 

ftp> quit 

ux1,1bl,gouz 


areteterecareteterete 


Fig. 9-11 An FTP session on TCP/IP. 


A compressed data mode is available in FTP to strip out unneces- 
sary data repetitions. This is again done with a control indicator, fol- 
lowed by a 2-byte code indicating the type of repetition. The first byte 
is how many occurrences are present; the second byte is for the char- 
acter to be repeated. 

Flow control is accomplished in several ways. First, the underlying 
TCP environment provides a form of buffering and flow control. 
Second, a block mode is available that lets files be transferred in a 
start/stop mode. 

An FTP implementation actually consists of two separate TCP con- 
nections. One is used for commands and responses. The channel is 
used for data and acknowledgments. Usually, these two connections 
have different TCP flow control parameters (window sizes, etc.). 

On most systems, TCP/IP services are implemented as part of the 
kernel functions. This is usually the case for both Unix and VMS. 
This is because both modules provide services for a variety of different 
users and interact with low-level device drivers. The FTP module, like 
the DNA DAP module, executes in user space to avoid violating file 
access protection by executing in the wrong context. 
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SMTP mail protocols 


The Simple Mail Transfer Protocol (SMTP) is a set of standard com- 
mands for exchanging mail messages between systems. SMTP makes 
no attempt to define the nature of the user interface or the local 
functionality that is available) SMTP also does not necessarily 
operate for transfer of mail between users on the same node. A native 
mail system may be invoked for this function. 

SMTP functions by examining a special queue area on the file sys- 
tem. If messages are present on that queue, a TCP connection is ac- 
tivated on port 25 and a remote SMTP module is notified to accept the 
messages. SMTP receivers either queue the message locally or place 
it back into an SMTP queue for forwarding to another system. 

SMTP sessions consist of a series of commands, each one of which is 
acknowledged by a reply. Often the reply consists of a simple status 
code indicating success. Other times, as in the case of expanding a 
mailing list name into its membership list, the reply is quite exten- 
sive. 

The session begins with both sides exchanging HELLO messages to 
identify themselves. This is followed by a series of commands that 
indicate that a message is to be sent and receipts are needed and by 
data commands that actually transfer the data. By separating the 
data message from the address field, SMTP allows a single message to 
be delivered to multiple users. 

Several other SMTP commands help enhance the utility of the pro- 
gram. A TURN command allows the two nodes to switch the roles of 
sender and receiver, a VERIFY commands allows user names to be 
verified, and the EXPAND command expands mailing lists. 

SMTP modifies every message that it receives and adds a time 
stamp and a reverse path indicator into each message. This means 
that a mail message in the SMTP environment usually consists of a 
fairly long header with information from each node that handled the 
message. Many user interfaces are able to automatically filter out 
that information unless users have some bizarre interest in reading it. 


TELNET virtual terminal service 


The TELNET service is a virtual terminal service. Both user and 
server components are available, depending on the role and power of a 
particular machine. PC-DOS systems implement only the user side of 
TELNET, because of the single-tasking nature of the operating sys- 
tem. 
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Like the DEC Virtual Terminal Service, TELNET is an attempt to 
fool an operating system into thinking that a remote terminal is really 
locally connected. This means that all the software on the computer is 
able to function without consideration of the location of that terminal. 
TELNET was designed to work in a wide variety of different operating 
environments. In some environments, implementation is quite dif- 
ficult because of the tight integration of physical devices into com- 
mands. 

In a VMS environment, this is easily accomplished because of the 
two levels of device drivers. A device driver in VMS consists of a class 
driver and then a physical device driver. The class driver accepts calls 
for a general class of service, for example, terminal I/O. The physical 
device than accepts a call and transmits it to the actual device. Thus 
in this case, the terminal I/O class driver would send calls to the TEL- 
NET process rather than an asynchronous communications controller 
or a LAT driver. 

The TELNET service models a virtual terminal as a bidirectional 
character device. This typically means a printer or a screen and a 
keyboard. Some extensions to the model help support more advanced 
types of terminals (if you can call a VT100 advanced). 

Normally, echoing is performed locally. Most TELNET implementa- 
tions will perform local echoing except on a few special control charac- 
ters, such as an interrupt, abort ouput, or break signal. There is also 
an “are you there” key that is used to find out if the host is still active. 

TELNET is based on a half-duplex mode of operation. A turnaround 
signal switches the sending of data to the other side of the connection. 

During the TELNET setup phase, the user and server are able to 
negotiate for the support of expanded capabilities. This allows the 
specification of the number of lines on a full-screen terminal, for ex- 
ample. It also allows the specification of a specific terminal type, as- 
suming the host is able to support that type. Another possibility is 
remote echoing. In a 300 bps wide area link this is not a feasible 
option. However, if TCP/IP is being run over an Ethernet and the 
user has a full-screen editing program, it would make sense to allow 
remote echoing. 


Network File System 


The Network File System is a set of protocols developed by Sun 
Microsystems to supplement TCP/IP. A session layer protocol, RPC, 
allows interprocess communication across a network. The presenta- 
tion layer protocol, XDR, provides for a machine-independent method 
of representing complex data structures. Finally, NFS itself allows 
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uxl.lbl.gov% df 
Filesystem kbytes used avail capacity Mounted on 
/dev/xyBa 7751 6767 268 377% 7 
/dev/xyZa 7751 6698 285 367 Zt 
7dev/xy3g 278291 958043 148218 39% Zuxid 
/dev/xyif 225819 83983 119334 417% Zuxic 
Zdev/xyZh 238277 §©©84541 129988 shera Zuxib 
/dev/xyZg 238277 170931 43518 807 Zuxla 
7dev/xy8d 119999 78849 29958 727 Zusr 
/dev/xy3h 278291 68121 183148 VAsy A /usr/uxl 
7dev/xyle 44853 28881 11486 727 /usr/spool 
/dev/xylg 189785 128112 42694 757 Zusr/local 
/dev/xyef 356283 249339 71315 787% /usr/local/src 
/dev/xyid 14849 238 13126 27 7tmp 
helios:/usr 490648 438318 3266 = EVA /usr/helios/usr 
ux3.1b1l.gov:/usr. MC688Z8/ux3 

262069 zs 18163 VA Zusr/ux3 
ux3. 1b]. gov: 7ux3c 254483 37 228997 87 Zux3c 
ux3,1bl.gov:/ux3b 253813 158887 69544 707 Zux3b 
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Courtesy of Lawrence Berkeley Laboratory 


Fig. 9-12 File systems mounted with NFS. 


file systems to be mounted on remote nodes as though they were local. 
Figure 9-12 shows remote file systems mounted on a Unix node using 
NFS. 

The NFS family of protocols provides services from the session layer 
up. It is conceivable that NFS could be implemented on top of other 
lower-layer services, such as DECnet or XNS, but in practice it uses 
TCP/IP for the network and transport services. 

Although the networking portion of NFS is in theory network inde- 
pendent, the NFS service itself is fairly well tied into the Unix file 
systems. The Record Management Services on VMS provide many 
higher-level services, such as complex file structures, that are missing 
from the native Unix file system. Instead, in Unix, individual applica- 
tions provide that additional level of structure. The complex nature of 
the RMS file system makes implementation of the NFS under VMS a 
difficult task (although DEC has managed to do it). 

One of the factors in the widespread adoption of NFS as a de facto 
industry standard is the fact that Sun actively pursued licensing of 
the protocols by third-party vendors. As a result, several hundred 
vendors have implementations of NFS available. Implementations are 
available for most versions of Berkeley Unix, including DEC’s Ultrix, 
for VAX/VMS, for MS-DOS, and even for IBM large-scale operating 
systems such as VM and MVS. 

The key characteristic of NFS is that it allows different machines 
with different operating systems to share data and computing resour- 
ces. A PC can store data on a VAX running Ultrix and thus supple- 
ment scarce resources on the PC. Access to the data is transparent to 
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the PC and looks like an additional hard drive. Hosts can also have 
programs run on foreign hosts, thus supplementing CPU resources. 


Session layer services 


To provide a base for complex applications, Sun began by supplement- 
ing the UDP transport layer services with a session layer interface. 
This allows remote nodes to execute processes. Note that this was 
possible before, but both of the programs involved would have had to 
use the TCP or UDP interfaces directly. The addition of a remote 
procedure call (RPC) layer allows application programs to refer to 
remote process by name or number and not worry about preparing 
information for use by the network. 

RPC thus provides an extension of local memory on a system, where 
functions can be executed by specifying an address location. RPC 
functions can be executed and the results left in a prearranged local 
data structure just like a local function or procedure call. 

The RPC mechanism specifies which program on a remote node 
should be executed. The mechanism for returning information across 
that network is the external data representation (XDR). 

RPC can be accessed at three different levels. At the highest level, 
a series of programs is contained in a library. These programs shield 
all of the RPC and XDR details from the program and return informa- 
tion to the users. Examples of these services include: 


rnusers Returns the number of users on a node 
rusers Returns information on users on a node 
havedisk Specifies if that node has a disk 

rstat Remote data on kernel 


The lower two levels of RPC allow users to provide more detailed 
control over execution. The library interface is a mid-level interface to 
RPC. The low-level interface allows users to explicitly manipulate 
sockets and transmit RPC messages, and it would usually not be used 
unless special performance considerations dictate its use. 

Library interface access to RPC is done through two different ser- 
vice calls. The registerrpce call allows a procedure to be registered as 
available to foreign users. The callrpce() allows the execution of a 
remote call. 

Procedures in RPC are grouped into programs, each one consisting 
of a family of related procedures. Programs can have program num- 
bers associated with them to keep track of versions of a similar 
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library. Finally, each procedure within a program has a procedure 
number. 

A callrpe call specifies which remote machine, program, version, 
and procedure number are desired. Additionally, the call specifies 
where the arguments to the call are located and the types (data struc- 
ture) of the argument. There is also a pointer and definition of a data 
structure used to store the results. 

The rnusers call discussed earlier provides the highest level of in- 
terface to the remote procedure. The rnusers() call ends up issuing a 
library interface call in the form of: 


if ( callrpe ( argv[1], 


RUSERSPROG, /* RPC PROGRAM NUMBER */ 
RUSERSVERS, /* RPC VERSION NUMBER */ 
RUSERSPROC_NUM, /* RPC PROCEDURE NUMB */ 
xdr_void, /* Null Data Structure */ 
0, /* Null Pointer */ 
xdr_u_long, /* Description of Results */ 
&nusers /* Results Area */ 

) 
=70)) 
{ exit(1) }; 


The data structure definitions are actually XDR routines provided to 
translate local data into XDR format and vice versa. The xdr_void 
call above specifies that no translation occurs because there are no 
parameters to translate. 

The callrpe service uses the UDP protocols at the underlying 
transport level. The RPC definition at the very lowest level allows 
tuning of the number of retries that RPC will attempt before returning 
an error message. It also allows the use of different transport layers 
(i.e., TCP for reliable transport). 

User programs of RPC work through a service daemon on their 
machines. The analogous VMS concept is a detached process. The ser- 
vice daemon in turn communicates with a service daemon on a remote 
node. Finally, the remote service daemon communicates with the tar- 
get program that is to be executed. 

Servers in the RPC environment begin by registering all of the RPC 
calls they plan on handling. The server then goes into an infinite loop 
and waits for calls from clients. 

There are two types of RPC operation. Normal RPC operates in a 
nonbroadcast network environment. This means that every request 
results in one answer. Broadcast mode sends the RPC calls out over a 
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broadcast medium (usually Ethernet). Several answers may be 
returned for a single call. In the case of a program like netstat, all of 
the answers are relevant. Other calls may expect only one answer 
and throw the others away. 

Security is one of the functions that are provided at the RPC level. 
Three types are provided. No security means that no authentification 
of calls is provided. A DES-type security and Unix-style scheme are 
also available. 


Presentation layer 


The External Data Representation (XDR) allows an implementation- 
independent way of representing information. This is important be- 
cause even integers are represented differently on a VAX and on a 
Sun Workstation. On one system the first bit is considered to be the 
most important, while on another it is the last bit that is most sig- 
nificant. Thus, even though the machines have the same size words, 
they interpret them differently. 

This phenomenon can be seen by using the echo command on a 
VAX with the Ultrix operating system. This command simply echoes 
back the character string it receives. The rsh command takes the 
result of this echo and feeds it to a remote machine. There, the cat 
command simply lists the data it receives. Notice that the 1 on a VAX 
has turned into a very different number on a Sun: 


vax% echo 012 3’ 

0.1.2:3 

vax% echo ’0 1 2 3’ | rsh sun cat 
0 16777216 33554432 50331648 


Portability problems with integers are nothing when compared to 
more complex data structures. For example, pointers or floating point 
numbers have very different representations in different environ- 
ments. XDR is able to translate machine information into the XDR 
representation and then deserialize the information back into the 
machine-dependent form. 

Standard routines are provided in the XDR library for short and 
long integers, floating points, and boolean data. Strings and fixed and 
variable arrays are also defined. A special kind of data is opaque 
data, which means that the XDR library passes the data through 
without translation. Opaque data is used in security systems to pass 
authentification handles. Users are also able to set up their own XDR 
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translation routines, which build more complex structures on top of 
the basic routines. 


NFS services 


The Network File System uses the RPC and XDR layers. The main 
function of NFS is to provide a remote mount of a file system. NFS is 
very similar to the DEC Distributed File Service discussed earlier. An 
important difference is that NFS is stateless—no connections are 
maintained with clients. This means that if a server aborts, the 
client is not forced to wait indefinitely for the server to recover. Fig- 
ure 9-13 shows Ethernet traffic on the Ethernet. Figure 9-14 shows 
an NFS read operation. 

Distributed file systems allow certain nodes to specialize in certain 
tasks. A common use of NFS is to allow user files to be stored on one 
large machine and then remotely mounted on the workstation that the 
user is currently logged into. No matter which node of the network 
the user is physically on, the same file space is seen. 

NFS has several features to help performance, including a read- 
ahead and write-behind cache. The read-ahead cache means that 
extra information can be cached at both the client and the server, 
alleviating the need to return to the disk drive to get more informa- 
tion. 

The write-behind cache means that information is not immediately 
added to the disk before the next operation can proceed. Obviously if 
either the server or the client goes down, the cache can be lost. Fre- 
quent flushing of the cache to disk helps prevent lost data. 

By itself, NFS has no state. This means no locks or file open com- 
mands are provided in the NFS service. A separate locking service is 
available to provide consistency guarantees. It is up to the individual 
application to first use the services of the lock manager, then request 
the data. For this mechanism to provide consistency across multiple 
users, it is important for all user applications that access the data to 
first consult with the lock manager. 

NFS defines a basic series of file operations, including read, write, 
create, and destroy directories, files, and file attributes. Once a par- 
ticular file ID has been retrieved, the user can retrieve data from the 
file by specifying the starting address and the amount of data re- 
quested in bytes. 

Special files, a unique mechanism that allows a user to read and 
write to a device as though it were a file, are unavailable in the NFS 
environment. Special files are used in Unix to implement locking and 
other virtual services. 
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fi] NFS-user 2 NFS R OK F=@519 

Ee Argus ¢NFS-user NFS C Lookup dbcom.,h in F=@519 
ea] | NFS-user +Argus NFS R OK F=4C18 

S Argus +NFS-user NFS C Lookup ccom in F=42@E 


NFS-user +Argus NFS R OK F=520E 

Argus +NFS-user NFS C F=52@E Read 4096 at 89088 

NFS-user +Argus NFS R OK (4896 bytes) 

(36.56.8@.208] +f{36.53.8.195] IP D=(36.56.8.288)] S=(36.53.8.195] LEN=21 

NFS-user +Argus UDP continuation ID=52261 

Argus +(36.22.8.116] DNS C ID=2688 OP=QUERY NAME=litho. stanford. 
NFS-user +tArgus continuation ID=52261 

(36,53,8.195] +{36,56,@, 208) D=(36,53,.8,195] S=(36,56,8,288] LEN=21 

(36.56.8.208] +{36.53.8.195] D=(36,56.8.208] S=(36.53.8,.195] LEN=20 

(36.22.8.116] +Argus R ID=Z2688 STAT=0K NAME=litho.stanford.e 
Argus +NFS-user C F=520E Read 4096 at 99328 

NFS-user +tArgus R OK (4096 bytes) 

(36,56,@,208) +{36,53,0,195) D=(36, 56,8, 288] S=[36,53.8,195] LEN=21 

NFS-user targus continuation ID=52773 

NFS-user +Argus continuation ID=52773 

(36.53.8.195] +(36.56.8. 208) D=(36.53.8.195)] S=(36.56.0.208] LEN=21 
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Fig. 9-13 NFS traffic on an Ethernet. 


Security in the NFS environment is fairly weak and is based on 
Unix-style commands. A future NFS enhancement may require an 
authentification server. Usually, NFS security is built on two levels. 
When the Unix-style RPC authorization is used, an authorization 
handle is passed consisting of a group and individual ID. NFS then 
checks these with the local (Unix-style) group and individual ID 
protection for the file desired. This implies consistent assignment of 
IDs across the network, hence the need for the Yellow Pages, dis- 
cussed in the next section. 

A special security case is the Unix superuser account. This 
privileged account on any Unix account always has a group/user ID of 
0. This would imply privileged access on one machine automatically 
granting privileged access on any other machine of the network. 
Needless to say, a single security violation on one node can thus com- 
promise the whole network. This defeats one of the purposes of a dis- 
tributed processing environment, which is to allow distributed 
management of different nodes on the network. NFS handles this 
situation by automatically changing superuser IDs to -2 before 
processing the security check. 
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Proc = 6 (Read from file) 
Status = @ (0K) 
File type = 1 (Regular file) 
Mode = 9180666 
Type = Regular file 
Ouner’s permissions = ru- 
Group’s permissions = rw- 
Others’ permissions = ru- 
Link count = 1, UID = 182, GID = @ 
Block size = 4096, Rdev = @, Number of blocks = @ 


File system id = 2308, File id = 4162 
Access time = Dec 1@ 1986 19: 20: 38.65803Z GMT 


Modification time = Dec 18 1986 19:2@0:38.8042497 GMT 
Inode change time = Dec 1@ 1986 19:20:38.042497 GMT 
(@ byte(s) of data] 


CNormal end of ‘SUN 
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Fig. 9-14 Reading data in an NFS packet. 


Yellow Pages 


The Yellow Pages (YP) is a set of utilities designed to simplify system 
administration. It is a set of replicated, read-only databases that con- 
tain network information. For example, a Unix password file is usual- 
ly maintained by using the Yellow Pages. This allows one password 
space to be maintained for large complex networks. Additionally, each 
node can have its own customized password file that is not available 
through the Yellow Pages. 

The Yellow Pages consists of a series of maps. A hosts map, for 
example, contains a series of host names and the resulting IP address 
as values. Standard Unix files that keep track of user passwords, 
group assignments, hosts on the network, and networks available to 
this subnet are all candidates for conversion to the Yellow Pages. It is 
then up to the programs that use these files to know that they are 
Yellow Pages files. 

The Unix passwd command thus had to be rewritten to look for the 
password file on the Yellow Pages. The rewritten command also 
checks on a local file to see if the local machine has any changes to the 
network-wide namespace. 

One important implication of converting a file to use the Yellow 
Pages is that the system designer may not know all the different ways 
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that a file is used. In the Unix environment, for example, one user of 
the /etc/passwd file was the passwd command. This was rewritten 
to know about the Yellow Pages. However, an old trick to find out 
information about yourself is to issue the following command: 


unix% cat /etc/passwd | grep username 


The cat command says list the /etc/passwd file which is then 
passed into the grep utility which looks for a particular user name. 
This would be a way to find out default log-in areas or other relevant 
information. However, the file /ete/passwd no longer exists and this 
little utility would fail. This is a potentially severe problem in a Unix 
environment where utilities tend to last for many years and propagate 
in unexpected forms. 

YP can thus be thought of as a stripped-down version of the DNS 
nameservers which allow a directory (roughly equivalent to a map) to 
be replicated in several locations. In the YP environment, one YP 
server is designated as the master for a map. Servers also maintain 
copies of maps for which another server is the master. 

A YP daemon is present on each node that will provide Yellow 
Pages services to the network. The user program on the client node is 
usually implemented as a high-level RPC call. Each node has a yp- 
bind daemon which links to a particular server for maps. If that 
server goes down, the ypbind daemon on the client is able to broad- 
cast a plea for help and rebind to a new server. The ypwhich com- 
mand shows current binds in the yellow pages environment. 


TCP/IP Implementation 


Implementation of TCP/IP networks is very similar to that of DNA 
networks. This is because both architectures incorporate Ethernet 
and X.25 subnetworks by reference. The differences between the two 
networks appear in the upper-level services, such as nameservers, dis- 
tributed file servers, messaging systems, and other network-based ap- 
plications. 

DEC supports TCP/IP for both Ultrix and VMS VAX systems. The 
same Ethernet board is used as is in a DNA environment but with a 
different protocol stack implemented in software. DEC also supports 
the Network File System on both operating systems. The same Ether- 
net board is able to simultaneously support DNA and TCP/IP protocol 
stacks. A node with both protocol stacks active serves as a gateway 
between the two networking environments. 
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DNA and TCP/IP enviornments can be loosely connected using the 
DECnet-Internet gateway which is part of the DECnet/Ultrix im- 
plementation. This software allows a mapping between the rep and 
DAP protocols, between SMTP and DECnet mail, and between the 
TELNET and CTERM virtual terminal services. Using this gateway, 
users on a DNA node can establish a DNA link to the Ultrix gateway 
and then establish a TCP/IP link out to their final destination. 

In addition to supporting Ethernet and X.25 as TCP/IP subnet- 
works, DEC also allows NFS to be used on a CI bus. As in a SCA- 
based cluster, up to 16 nodes can use the CI bus. These nodes can be 
HSC controllers or VAX systems. The HSC controllers and VAX sys- 
tems on the cluster communicate with each other using the NFS 
protocols. 

Equipment for a TCP/IP Ethernet environment is very similar to 
DNA equipment. An example are TCP/IP based-terminal servers 
made by Bridge/3Com. These devices use the same modular strcture 
as the DECserver 500 where several line cards can be installed, each 
supporting multiple users. As in the case of DEC terminal servers, 
RS-232 ports or 50 pin connectors are supported for asynchronous ter- 
minals. 

In addition to asynchronous connections, the bridge terminal servers 
support synchronous terminals. Instead of a series of RS-232 ports, a 
synchronous line card has a series of BNC connectors for IBM 3270 
terminals. Both types of terminals can be mixed on a single terminal 
server. Support for synchronous terminals is, of course, not a 
capability of the network but of this particular piece of hardware. 

Like the DECserver 500, the software is downline loaded from a 
support host. In the case of the bridge terminal server, the support 
host is the Bridge Network Control Center, which is based on either a 
dedicated PC/AT or Sun Workstation hardware platform. This differs 
from the MOP protocols that can use any Phase IV host on the net- 
work to downline load boot images. A particular terminal server is 
able to downline load either TCP/IP, XNS, or the OSI virtual terminal 
protocol suite. 

Although DEC does not make a TCP/IP terminal server, they do 
support the protocols on their host systems. Standard DEC equip- 
ment, such as transceivers, DELNIs, or Ethernet bridges can also be 
used in a TCP/IP environment. MHigher-level services, such as ter- 
minal servers or TCP/IP routers, can then be obtained from a wide 
variety of sources. 

It is important to understand that DNA and TCP/IP offer com- 
plementary services. It is not unusual to see both networking 
protocols in a single installation. TCP/IP operates on a wider 
hardware base than DNA does. However, because DEC focuses on a 
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limited number of hardware platforms, they are generally able to pro- 
vide specific functionality and performance tailored to their equipment 
and software. 


Summary 


TCP/IP, together with the NFS services, provides a valuable alterna- 
tive to DECnet for heterogeneous networking enviornments. Many re- 
search organizations find they are unable to restrict nodes in a net- 
work to a certain brand, or even to those that support DECnet. For 
these organizations, TCP/IP is a viable choice for a networking 
protocol. 

In many organizations, TCP/IP and DECnet coexist to form a com- 
mon network. The DECnet-Internet gateway, or other nodes that par- 
ticipate in both environments, form a bridge of connectivity. It is not 
unusual to see both network architectures coexist on a single Ether- 
net. 

NFS provides a de facto standard for distributed data access in a 
Unix or Internet environment. Although NFS is a de facto standard, 
it is important to look at the actual implementations from each vendor 
to make sure they use the same portions of the standard. For ex- 
ample, DEC’s VMS implementation of NFS uses the VMS distributed 
lock manager which was described in the Cluster chapter of this book, 
while Sun implementations would use another lock manager. Applica- 
tions that write directly to a lock manager need to take into account 
these differences. For users who simply wish to read data over the 
network, these differences are not significant. 

Both TCP/IP and DNA are rapidly converging in the form of the OSI 
protocols. After a brief diversion on SNA, this part will discuss Phase 
V of DECnet, which is an implementation of the OSI protocols. 
TCP/IP has been replaced by OSI as the official government-supported 
networking protocols in the United States. This convergence provides 
the means for interconnecting previously seperate environments. 
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System Network Architecture 


Overview of This Chapter 


Although DEC and IBM computers are usually purchased for different 
operating requirements, it is very common to find both types of equip- 
ment in the same environment. The local area network chapter dis- 
cussed connection of workstations such as the IBM PC, in the context 
of connecting the PC to the DNA environment. 

This chapter discusses the high end of the IBM environment, using 
the System Network Architecture. It is also possible for PCs to par- 
ticipate in the SNA environment, using token ring adapters and other 
LAN technology. However, in discussing DNA-SNA connectivity, we 
focus on communications between DNA Phase IV end nodes and IBM 
hosts. Since a PC can be a Phase IV end node, it is possible to con- 
nect PCs to the SNA environment using DECnet. 

Connecting to the SNA environment can use either a dedicated 
gateway or the services of a general-purpose VAX. As with X.25 con- 
nections or DECnet routers, different speeds are available for these 
connections. With the high end DECnet/SNA CT gateway, speeds of 
1.2 mbps can be achieved. Low-end connections using a stand-alone 
MicroVAX or BI VAX connections of 9.6 to 64 kbps are also available. 

The gateway, whether on a general-purpose VAX or a dedicated 
gateway, only provides the basic level of connectivity. Services are 
provided by access routines, which can provide very simple services 
such as terminal emulation. More advanced services are available to 
interconnect office and mail systems together or to provide 
transparent access to databases in the SNA environment. 
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For high-volume, low-functionality services such as remote job entry 
or 3270 terminal emulation, there are several alternatives to gateways 
that will be considered. These include protocol converters and data 
switches. Often, these direct connectivity methods are supplemented 
with a gateway to provide more advanced services. 


Network Addressable Units 


When describing DEC networking architectures, very little thought is 
given to the type of machines that are connected in a network. With 
very few exceptions, VAX computers are interchangeable, with only a 
difference in performance between different types of processors. The 
only real exception to this rule has been in the limitation against 
MicroVAX and other Q-bus based processors using the 70-mbps CI bus 
in clusters. The limitation here was only performance related, be- 
cause of the ability of Local Area VAX Clusters to provide the same 
System Communication Architecture functionality across the Ethernet. 

In the IBM world, the type of hardware makes a big difference for 
the different connectivity options available. This is because of the 
gradual evolution within IBM of different hardware product lines. As 
will be seen at the end of this chapter, IBM’s System Application Ar- 
chitecture (SAA) is an attempt to blur the differences between kinds of 
hardware. 

The basic purpose for IBM’s System Network Architecture was 
originally as a method for connecting many terminals to a System 370 
architecture host. This is quite different from DNA’s original aim of 
providing peer-to-peer communication. This is not to say that IBM 
nodes do not have this capability—only that the capabilities were 
grafted onto the networking architecture at a later point. 

The basic IBM hardware configuration consists of an IBM 370 ar- 
chitecture host, such as the 3090 series. The host provides com- 
munications to the rest of the SNA network through channels. These 
channels provide a maximum throughput of 3 to 5 Mbps, although 
most devices that connect to the channel operate at T1 speeds or less. 
A 370 host is known as physical unit type 5 in SNA. Figure 10-1 
shows the different physical units in an SNA network. 

Attached to the host is a communications controller. The com- 
munications controller is PU type 4. Attached to the communications 
controller are a series of cluster controllers, such as the 3274. The 
cluster controller is a PU type 2. A series of terminals attach to the 
cluster controller. 

The communications controller is responsible for maintaining com- 
munications paths with all the various cluster controllers. In addition, 
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SYSTEM SERVICES CONTROL POINT 


HOST CPU: PU Type 5 (VTAM) 


COMMUNICATIONS CONTROLLER 
PU Type 4 


CLUSTER CONTROLLER 
PU Type 2 


Fig. 10-1 Logical and physical units in SNA. 


token ring networks can be attached to newer models of the cluster 
controller, the 3174. 

In the traditional SNA terminal environment, in which terminals 
are connected to a host, all communications are routed to the 
mainframe computer. The terminal is represented by software or 
microcode on the cluster controller. This is known as a logical unit 
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(LU). Each of these LUs is a part of the SNA network, known as a 
network addressable unit (NAU). That node then has another NAU, 
the physical unit, to manage the physical characteristics of the node. 

When the terminal connects to a host computer, the terminal’s LU 
initially communicates with a special NAU called the system services 
control point (SSCP). The SSCP is the central point of control on the 
host, and it assists in establishing a session between an LU on the 
host and an LU representing the terminal. To initiate this process, 
the LU sends a BIND request to the SSCP. 

SNA capabilities on the host are funneled through a subsystem on 
the host called the Virtual Telecommunication Access Method (VTAM). 
VTAM is the implementation of SNA services for 370 architecture 
hosts and runs under the various IBM operating systems that support 
SNA, such as VM or MVS. 

Although SNA hosts have a single instance of VTAM, there are 
several different applications subsystems available for users. In an 
MVS environment, batch users use the Job Entry Subsystems (JES), 
while interactive users will use the Time Sharing Option (TSO) or 
CICS. On the VM operating system, the Conversational Monitor Sys- 
tem (CMS) provides interactive services to users. 

Different logical units in the IBM environment have different sets of 
capabilities. A terminal and a printer, for example, have different 
buffer sizes and operational characteristics, and they support different 
data streams. An LU type 2 is essentially a terminal session. A more 
advanced type of LU is the Advanced Program-to-Program Com- 
munication (APPC) function, or LU6.2. LU6.2 allows direct peer-to- 
peer communication between cooperating processes. 

As was discussed, traditional SNA communications involve the ser- 
vices of a host processor. In a token ring environment, this is not a 
very efficient method of providing PC-to-PC communications. A more 
modern type of PU is the PU type 2.1 which allows peer-to-peer com- 
munications without using the services of a PU type 5 or host. 


SNA protocol stack 


Like DNA, SNA is a layered protocol stack. At the lower layers, SNA 
supports three types of data link protocols. The basic protocol is the 
Synchronous Data Link Control (SDLC). This serves the same pur- 
pose as DDCMP of providing direct point-to-point connectivity between 
hosts. SDLC is a subset of the more general HDLC protocol discussed 
in the next chapter of this book. Figure 10-2 shows the layers of the 
SNA protocol stack. 
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NAU SERVICES MANAGER 


FIL.LFMD PRESENTATION 
SERVICES 


DATA FLOW CONTROL 


TRANSMISSION CONTROL 


PATH CONTROL 


DATA LINK CONTROL 


PHYSICAL 


Fig. 10-2 Layers of the SNA protocol stack. 


Token rings are another data link protocol supported in the IBM 
environment. A 9370 host, as well as PC or PS/2 systems can all 
connect to these token ring systems. The token rings operate at a 
speed of 4 mbps. 

The third connectivity option is to use X.25 as a data link protocol. 
An X.25 virtual circuit is established between two different SNA sys- 
tems and SNA protocols are then embedded within the X.25 packet. 
IBM uses their Network Packet Switching Interface (NPSI) package as 
a method of using X.25 networks to transport SNA information. Fig- 
ure 10-3 shows an IBM network using a combination of data link 
protocols. 
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Fig. 10-3 SNA network configuration. 
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Any of the three data link types sends information to peers using a 
link header. Embedded within this link header are the higher layers 
of the protocol stack. The path control layer provides routing func- 
tions within the network by embedding a transmission header after 
the link header. 

The primary function of the transmission header is to send data to 
the eventual destination. This destination could be to a host within 
this SNA domain or it could be to another domain of the SNA network 
using the Multiple Systems Network Facilities. 

The transmission header is followed by a request header. The re- 
quest header is then followed by a set of request units (RU). The 
upper layers of the network communicate with each other using these 
request units. RUs may indicate presentation layer information (the 
FI.FMD layer of SNA), or user data. 

A packet of SNA thus consists of: 


a A link header 

a A transmission header 

ws A request header 

a» One or several request units 


When an LU-to-LU session is initiated, a maximum RU size is 
defined, which may be smaller than the size of the path control mes- 
sage. Several RUs can be chained together within a single packet. All 
RUs are chained although often the chain consists of a single RU. 
Figures 10-4 and 10-5 show different SNA packets on a token ring 
that illustrate link, transmission, and request headers. 

If all the data can be sent as a single chain, the application or other 
user of the path control layer is able to use a bracketing function. 
Bracketing allows series of chains that consist of a major unit of work 
to be bound together as a single logical message. Brackets are similar 
to major synchronization points in the OSI upper-layer protocols. 

In contrast to the DNA environment, it is possible for a session to 
negotiate throughput parameters and other forms of quality of service 
indicators on a per-session basis. The IBM Network Control Program, 
which manages routing functionality, has a series of paths defined in a 
routing table. These routing tables must be manually defined by the 
system manager, in contrast to the dynamic routing capabilities of 
DECnet. 

Built on top of the basic SNA architecture are a series of upper- 
layer architectures used for connecting peer systems. The discussion 
of DEC connectivity to the SNA environment begins with connection to 
the basic SNA environment, then goes on to discuss these upper-layer 
architecture such as those used for office systems connectivity. 
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Fig. 10-4 A request header. 
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Fig. 10-5 Data link and transmission headers. 
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DNA/SNA Interconnection Strategies 


The different types of SNA nodes, corresponding to different physical 
units, provide a ready format for connection to the IBM environment. 
Non-IBM environments connect to SNA by emulating a type of physi- 
cal unit. Emulating a PU type 2 is the usual method for implementing 
an SNA Gateway. This makes the DEC environment look like a 
cluster controller with a series of logical units attached to it. 

Another option is to emulate a simple terminal. This means that 
the non-IBM environment does not need to provide the full services of 
the PU type 2 node. Instead, a PC or VAX can emulate the SDLC 
protocols and the 3270 data stream. Often, this method of intercon- 
nection provides a significantly cheaper and more efficient intercon- 
nection method than a fully functional gateway. This is analogous to 
having a PC emulate a VT100 terminal instead of functioning as a 
Phase IV end node in DNA. 


DECnet/SNA Gateway 


The DECnet/SNA Gateway is the same piece of hardware that is used 
for providing DNA routing and X.25 connectivity services. Like X.25 
and DECnet Routers, the DECnet/SNA Gateway uses the PDP and 
MicroVAX chip sets and supports a variety of transmissions speeds. 

It is important to understand that the basic DECnet/SNA Gateway 
does not provide any functionality for end users. By itself, the 
gateway does not emulate a terminal or provide print services or any 
other functions. The gateway instead provides the software routines 
to map SNA sessions to DNA logical links and to manage all the SNA 
protocols. A separate access routine is then required to provide the 
upper layer functionality. The access routine communicates with the 
gateway over DECnet using a Gateway Access Protocol. 

Three types of dedicated gateways are available. The first is the 
DECnet/SNA Gateway, Version 1.4. This gateway is identical to the 
DECSA Router and X.25 Gateways and is based on the PDP-11 
machine architecture. Up to two 64 kbps connections can be sup- 
ported on this device with a maximum of 32 simultaneous sessions. 

The next level of performance is provided by the DECnet/SNA 
Gateway for Synchronous Transport. This device, based on the same 
MicroVAX chip set as the DEMSA Router, is able to support a greatly 
increased level of connectivity. Up to four 64 kbps connections or a 
single 256 kbps connection can be supported on this device with a 
maximum of 128 simultaneous sessions. 
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The highest level of performance is the DECnet/SNA Gateway for 
Channel Transport (CT). This system provides a direct channel at- 
tached to a System 370 architecture mainframe with potential line 
speeds of 1.2 mbps and a maximum of 255 simultaneous sessions. 
Only a single attachment is supported on each CT Gateway. The CT 
Gateway connects to the IBM channel using standard bus and tag 
cables. 

All three gateways provide the same functionality but have different 
performance characteristics. It is possible for a single DECnet net- 
work to have multiple SNA gateways. These gateways may all go to 
the same host environment or may go to different SNA networks. The 
link between SNA gateways can be a local connection or can use the 
facilities of wide area transmission providers. 


Third-party gateways 


Interlink provides a gateway to the SNA environment which is built 
on a platform of DEC equipment. The Interlink Network Controller 
provides value-added services on two different types of DEC products. 
PDP-based versions offer throughput up to 50 kbps, while the 
MicroVAX-based versions offers data transfer rates up to 500 kbps. 

Interlink uses a different strategy. from DEC to implement 
gateways. DEC attempts to place almost all of the software on the 
DEC side, in the form of a SNA gateway manager and access routines. 
By the time the request has reached the IBM environment, it is in a 
standard IBM format, such as a 3270 data stream. 

Interlink, by contrast, puts a great deal of software on the IBM sys- 
tem. In fact, for file access, no software is needed on DEC client nodes 
and very little is used on the gateway node. On the IBM system, 
however, Interlink provides an implementation of the File Access Lis- 
tener (FAL). 

As in the case of DEC’s Data Transfer Facility, Interlink allows 
standard VMS commands such as COPY or TYPE to work with the IBM 
system just as they would with any other DECnet node. Users on the 
DEC system refer to IBM files by the same NODE::FILENAME syntax. 
In order to hide file system differences, the file specification is the one 
used for “foreign” files on a VMS system: 


node"username password account"::"filename/options" 
In addition to the standard data access capabilities, the gateway 


supports a variety of advanced capabilities. Task to task program- 
ming is available with a custom library. IBM users are able to access 
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the DEC environment. Bidirectional terminal emulation is also 
provided. Finally, DEC users have access to MVS JES facilities to 
access batch and print queues. 

IBM users are able to use a series of ISPF panels of a command 
interface called network file transfer (NFT). ISPF is a mainframe- 
based dialog manager, a utility that presents users with a standard 
set of panels used to execute system tasks such as starting up an 
editor, submitting a batch job, or printing a file. These birdirectional 
capabilities are very similar to those offered by DEC. 

Interlink requires that a single Network Controller be dedicated to 
an IBM host. The connection is directly into the host and does not 
offer the option of instead using the services of a communications con- 
troller. The direct channel attachment for the Interlink Network Con- 
troller provides aggregate maximum speeds of 500 mbps. This 
capability is similar to the CT version of the DECnet/SNA Gateway. 

While the Network Controller can only connect to a single host, it is 
able to connect to multiple DECnet environments. Any DNA-sup- 
ported controller is available as long as it is compatible with the Q-bus 
structure of the Network Controller. For Ethernet data links, a 
DEQNA Ethernet controller is used. For a DDCMP link to VAX sys- 
tems or DECnet routers, a DHV11 or DSV11 controller is used. Fig- 
ure 10-6 illustrates the structure of the MicroVAX-based Network 
Controller. 

Another option is the Flexlink 9750D system based on a dedicated 
piece of hardware called FastPath from Intel. This is not an SNA 
gateway in the sense of providing SNA services to the DEC environ- 
ment. Instead, custom software is provided in both the IBM and DEC 
environments to communicate with the Fastpath hardware. 


Direct host connections 


An alternative to using the services of a dedicated gateway is to pro- 
vide gateway functionality on a general-purpose VAX processor. The 
decision to use the services of a VAX versus a dedicated gateway is a 
function of the amount of traffic and the load patterns between the 
two different environments. If the purpose of an SNA connection is to 
load batch jobs in the middle of the night, it would make sense to use 
the existing VAX resources instead of buying a new gateway. 

DEC’s VMS/SNA package allows a VMS processor to be an SNA 
gateway. As with the dedicated gateway, this only provides network 
connectivity. Access routines must be provide separately. These ac- 
cess routines must be on the same VAX that is providing the SNA 
connectivity. The gateway, by contrast, provides a network-to-network 
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Fig. 10-6 Interlink SNA gateway structure. 


connection by allowing access routines to reside anyplace on the 
DECnet. 

VMS/SNA is a software package. It must be supplemented by a 
synchronous communications board that supports the SDLC data link 
protocols. On a CI bus system, this would typically be the DMB32 
processor, which is capable of supporting a single 64 kbps connection. 
For MicroVAX processors using the Q-bus, the DSV11 processor 
provides the same transmission speeds. 

As with any communications functions provided on a general-pur- 
pose VAX, it is important to understand that a significant portion of 
CPU resources will be used to provide this functionality. Some access 
routines, such as Remote Job Entry (RJE) can consume significant 
portions of a VAX processor. The VMS/SNA package similarly con- 
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sumes CPU resources. These resources will not be available to other 
users of the system and thus have a cost attached to them. In decid- 
ing between VMS/SNA and a dedicated gateway (or third-party alter- 
natives to the two), it is important to consider VAX-based CPU cycles 
as one of the cost factors. 


Data switches and other front-end alternatives 


It is not always cost-effective to use a dedicated gateway or a VAX to 
provide SNA access. While this may be useful for connecting high- 
level office systems together, it may be overly expensive for a more 
basic service such as terminal emulation. It is possible to have both a 
gateway for machine-to-machine communications and some other form 
of connection for terminal-to-machine communications. 

For simple terminal emulation, there are a wide variety of solutions 
that do not use the resources of a VAX. Some vendors sell terminals 
with both a coax and RS-232 connection on the back that can be con- 
nected simultaneously to a VAX and an SNA system. 

Another solution is to use the services of a protocol converter to 
make one type of terminal able to speak both low level protocols. 
Often, both asynchronous and synchronous communications are of- 
fered on a PC. This allows a PC to switch between emulating a 
VT100 terminal and a 3270 terminal. While this is a cheap solution, 
it should be noted that it makes a fairly intelligent device emulate a 
fairly unintelligent terminal. 

A higher level of functionality is to connect the PC to both types of 
networks. It is possible for a PC to have both Ethernet adapters for 
DNA and token ring adapters for SNA. Usually, it is not possible on a 
single PC to have both facilities available simultaneously. On the 
PS/2 series, with their more advanced communications functions, this 
becomes more practical. 

Often, terminal emulation is used as a companion to more advanced 
services. Advanced services are provided on a host-to-host basis using 
the services of a gateway. Terminal emulation, on the other hand, is 
provided using a front-end network that switches the PC to the ap- 
propriate asynchronous or synchronous communications controller. 

A PBX is sometimes used as the front-end switching device. Often, 
these PBX systems offer protocol conversion services as part of the 
package. The PBX is connected to PCs as well as telephones. Also 
connected to the PBX are SNA ports, usually as a series of cables to a 
cluster controller in the machine room. DNA connections are provided 
by a series of connections between the PBX and either terminal ser- 
vers or asynchronous communications ports on a host. 
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Basic Services Integration 


There are three basic services, each offered as a separate access 
routine by DEC. These services are terminal emulation, printer 
emulation, and Remote Job Entry (RJE). Terminal emulation allows a 
VT100 terminal to emulate an IBM 3270 terminal. Printer emulation 
allows a DEC computer to emulate an IBM printer. Remote Job Entry 
allows a DEC computer to emulate an IBM RJE station, such as a 
card reader. Figure 10-7 illustrates the three basic services. 

These are termed “basic services” because there are a variety of dif- 
ferent solutions on the market. For example, either DEC or Interlink 
gateways can provide these solutions. There also numerous vendors 
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that sell host-based solutions. These can be software only or a bun- 
dling of an SDLC synchronous communication board with software. 

As discussed above in the alternative to gateways section, terminal 
emulation can be accomplished without the use of a host. If the host 
is to provide that service, as in the case of the 3270 terminal emulator 
from DEC, it is important to make sure that the gateway has the 
ability to handle the expected load. 

The DECnet/SNA VMS 3270 terminal emulator is an example of a 
basic service that works on the DECnet/SNA Gateway or VMS/SNA. 
This access routine uses the Gateway Access Protocol (GAP) to connect 
to the SNA gateway. The GAP is running on top of a DNA logical 
link. It is the responsibility of the SNA Gateway to map that logical 
link into an SNA logical unit. 

The 3270 session begins when the logical unit on the SNA side (the 
applications system) sends a bind request. The terminal LU then ac- 
cepts the bind request. The 3270 session then consists of the IBM 
system sending out a series. of panels (forms) to the terminal, which 
responds by filling the form out. 

The 3270 software is able to buffer a form in memory and thus 
make the asynchronous VT100 terminal behave like a synchronous 
terminal. When the user hits the ENTER key, the buffered form is 
sent from the access software up to the cooperating SNA application. 

The software provides two types of translation services. First, it 
translates ASCII into EBCDIC character sets. The user can change 
that mapping for custom applications. The second mapping is from 
the 3270 keyboard to the VT100 keyboard. It should be noted that 
this mapping is fairly difficult to accomplish in a way that will please 
all users because the keyboards are so dissimilar. 

The 3270 access routine is the one of the few which runs on a PC 
with DECnet-DOS. A PC with this access routine is able to directly 
access a gateway without invoking the services of a host. This method 
is an alternative to giving the PC an SDLC board or token ring adapt- 
er to allow it to connect directly to the SNA environment. Similar 
terminal emulation software exists for the Ultrix operating system. 

A complementary product to the 3270 access routine is the 
DECnet/SNA VMS Distributed Host Command Facility (DHCF). This 
access routine cooperates with the IBM Host Command Facility. 
IBM’s software was meant to allow a systems programmer on a 370 
architecture host to also control Series/1 and 8100 Information Sys- 
tems, all from one terminal. DEC emulates one of these foreign sys- 
tems to allow the IBM software to log onto the VAX that has the 
access routine. 

Once the IBM programmer is logged onto the VAX with the access 
routine, full access to the rest of DNA resources is available. There 
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are two important limitations to this access. First, the access is of 
course limited by the VMS security on each node of the network. The 
second limitation is that the IBM user has only line mode (“glass 
TTY”) access to VMS utilities. VT-100-dependent routines will not 
function properly. An exception to this is that applications on the 
VAX that use the Forms Management System (FMS) software are able 
to provide full-screen access to a 3270 terminal using the DHCF ac- 
cess routine. 

The DECnet/SNA VMS printer emulator (PrE) allows a VAX to 
emulate an IBM 3287 printer that is connected to an IBM 3274 cluster 
controller. The system with the PrE access routine is able to spool 
incoming data either to a disk file or to a print symbiont. 

PrE is a useful way to integrate VAX-based printers into a large 
SNA environment. This means that users of RJE services or interac- 
tive users of the 3270 service can route information back to a local 
printer. This is important in areas where the DEC and the SNA en- 
vironments are connected using a wide area link. A user of a 
MicroVAX II would be loath to fly to Topeka, Kansas, just to pick up a 
printout! 

Another use of PrE is as a downloading tool. Rather than sending 
the print job to a VMS print symbiont, the data is spooled to disk. 
From there, it could be reformatted and used for other disk-based sys- 
tems such as a home-grown database system. 

The third basic access routine from DEC is a Remote Job Entry 
facility. Assuming that users know JCL (the IBM batch programming 
language), they can submit jobs that form part of the Job Entry 
Stream (JES) subsystems. The RJE facility manages a queue of jobs 
from the VAX and submits them one by one to the JES2 or JES3 
subsystems. Output can then be spooled back to a file on the VAX. It 
is possible to use DAP facilities to spool the output to a different sys- 
tem than the originator. 


Programming Libraries 


DEC sells three different programming interfaces, each one supporting 
a different class of logical unit services. These are rarely needed by 
end users. Instead, they are usually used to build applications by 
DEC and third-party developers. Most of the advanced services dis- 
cussed in this chapter are built on these programming interfaces. A 
variety of similar libraries are available for the Interlink gateway. 

The DECnet/SNA VMS 3270 Data Stream Programming Interface is 
the simplest library. This provides an LU2 interface to the SNA en- 
vironment. The programming library is able to perform all the actions 
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of starting a session including receiving and interpreting the initial 
bind request and accepting the bind. 

The library also handles many of the flow control features of SNA. 
To do this, the software maintains a series of state machines for 
chaining, bracketing, and data flow control. This frees the program- 
mer from dealing with these issues. 

The interface can be used at two levels. At the lowest level, data 
stream mode, the user is responsible for building and interpreting 
3270 data streams. This implies a detailed knowledge of the IBM 
3270 data stream. 

A higher-level interface is provided in field mode. This provides the 
programmer with assistance in building a screen image. Data can be 
presented to the interface by fields, and forms can have updated field 
values processed. 

The software is able to process a bind request from the VMS pro- 
gram and terminate an SNA session. The software also is able to 
respond to an unbind from the SNA session or a failure of either DNA 
or SNA circuits. The VMS application defines an entry point at run 
time. In the case of a circuit failure or unbind, the application is 
notified at that entry point. 

A more basic set of routines is provided by the DECnet/SNA VMS 
Application Programming Interface (API). This provides support for 
programs in logical unit types 0 through 3. This library consists of a 
series of useful subroutines. For example, subroutines are provided to 
accept remote bind requests, send a bind request, or reestablish a con- 
nection. 

The API routines do help the user by providing low level support for 
path, data link, and transmission control. The user, however, must 
process all of the presentation services information such as a 3270 
data stream. The user must also respond to all request units, parse 
bind requests, and perform ASCII/EBCDIC translation. 

Programmers using the API will be either writing a cooperating pro- 
gram on the SNA side or cooperating with a previously written pro- 
gram to which they have a very carefully defined interface. 

The most advanced interface is the APPC/LU6.2 Programming In- 
terface. This set of routines lets users participate in an LU6.2 conver- 
sation with a cooperating process. The interface supports only a 
single session at a time, limiting somewhat the usefulness of this 
programming library. 

The software is able to respond to incoming requests and thus allow 
the VMS environment to provide services to SNA nodes. An example 
of this would be a mail receiver that was able to accept information 
from the SNA Distribution Services (SNADS). As mentioned earlier, 
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these functions are not normally ones that would be used directly by 
end users. 

The APPC interface has the ability to allocate and deallocate basic 
and mapped conversations. All the basic verbs are available to allo- 
cate and deallocate conversations, wait for data, send error messages, 
and perform other common APPC functions. Control operator verbs 
include the ability to activate a session, define remote operations and 
transactions, and to delete sessions. Nonsupported verbs are special 
synchronization verbs to backout and set synchronization points in a 
conversation. 


Integrating Data Access 


Several advanced routines can make data available across the SNA 
and DNA environments. These provide more functionality than the 
simple upload and download capabilities of RJE or printer emulation. 
These access routines fall into two main categories: 


a Integration of database systems 
s Integration of file systems 


The DECnet/SNA Data Transfer Facility (DTF) is a family of 
software that integrates MVS file systems with VMS RMS file sys- 
tems. The software consists of two pieces. On the VAX side, there is 
a VMS/DTF server. Another component, MVS/DTF is installed on the 
IBM host. Figure 10-8 illustrates a DTF session from a VAX. 

An important characteristic of DTF is that it is a bidirectional 
gateway. This software allows IBM users to access VMS facilities and 
DNA users to access the IBM environment. The software is integrated 
into the operating environments of both types of users so they are able 
to use familiar syntax to access data resources. 

The VMS/DTF server software allows a user to access DTF facilities 
on other nodes. It includes a checkpoint/recover utility that is used in 
case of communications failures. The server software also includes 
routines to perform data translation and to use GAP to access the 
SNA gateway. 

An optional utility, Transfer/DTF allows VAX systems other than 
DTF server nodes to have access to checkpoint and recovery services 
directly on their node in the event of a failure during file transfer. 

The VMS software has been integrated into the DCL command lan- 
guage. Using a standard DCL COPY command, the user is able to 
access VSAM and non-VSAM data sets on MVS operating systems. 
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Fig. 10-8 Data transfer facility operations. 


The user’s request is first parsed by the System Authorization Facility 
(SAF) which decides if the user is authorized to access the data. 

At the DCL level, commands supported include directory commands 
as well as standard file manipulation commands such as OPEN, 
CLOSE, READ, TYPE, and DELETE. Alternatively, programmers can ac- 
cess the facility using standard RMS calls or Datatrieve programs. 
DTF supports all standard RMS sequential I/O capabilities. 

The IBM software, MVS/DTF, consists of two parts. First, there is a 
VTAM application which communicates with the VMS/DTF server 
software to process requests. The server performs all data transla- 
tions so the host is not burdened with this task. 

Two other components of the MVS/DTF software consist of three 
user interfaces. One consists of an ISPF dialog panel for use in an 
interactive session. The second user interface is a TSO command 
processor which can be accessed from batch facilities. Finally, CLISTS 
(a concept somewhat like command files on VMS) can be used. Check- 
point and recovery capabilities are supported from MVS/DTF just as 
they are from the VMS/DTF server. 

The session between the VTAM software and the VMS/DTF server 
software consists of an LU type 0 session. LU type 0 provides very 
little structure and is essentially a “roll-your-own” SNA implementa- 
tion—the programmer must process most of the details of interacting 
with the network. Because the software was written using LU type 0 
programming tools, it offers a large increase in performance over 
standard facilities such as the RJE access routine. 

DEC chose to implement this facility using LU type 0 instead of 
other LU types (such as LU6.2) for a two main reasons. First, it sup- 
ports a full duplex protocol which provides for an efficient use of SNA 
resources. Second, LU6.2 implementations require the CICS applica- 
tion subsystem, which many MVS users do not have. 
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If DTF is run on a 56 kbps line, it is possible for up to 40 kbps of 
data to be transferred, assuming no other access routines are also 
using the services of the gateway. With the CT version of the 
gateway, throughput over 1 mbps can be achieved. Small files reduce 
throughput because of the setup costs. Running the gateway on 
VMS/SNA instead of a dedicated gateway can also reduce throughput 
up to 30 percent. Its important to note that these facilities are not 
free—the combination of DTF and SNA access can easily use up the 
better part of a MicroVAX or small BI-bus based VAX. 


Database access 


The next level of data integration is at the database level. Many ven- 
dors are beginning to provide gateways between database systems 
that run in the two processing environments. The basic goal is to 
allow a user to continue using a familiar user interface but to be able 
to access database facilities located in other processing environments. 
For example, a user of Ingres is able to use the Ingres/Star gateway to 
access IMS databases in the IBM environment. Users of Oracle’s 
SQL*Star product can access a DB2 database environment from at 
least one of the different user interfaces that Oracle offers. 

DEC has a product called VAXlink, which accesses IMS databases 
and VSAM files in a transparent fashion. A related product is VIDA, 
which can access Cullinet IDMS databases. VAXlink and VIDA are 
part of a broader architecture that allows user interfaces and data 
repositories to exchange data. 

The key to this architecture is called the Digital Standard Relation- 
al Interface. DSRI is a standard interface to database systems. A 
user interface does not store data—it presents and manipulates it. 
When a user interface needs data, it issues a DSRI call to any 
database on the system that supports DSRI (see Figure 10-9). 

Two DEC-supplied DSRI interfaces are Rally and Teamdata. Team- 
data is a spreadsheet like user interface that spares the user from 
having to learn data manipulation languages such as SQL. Rally is a 
slightly more sophisticated utility that allows users to manipulate 
databases and create simple applications. 

A user of Teamdata is able to switch user interfaces and not have to 
worry about restructuring the database or providing a new interface 
routine. This also allows the database to move locations since DSRI 
calls are transparent in a DECnet environment. 

The recipient of a DSRI call is responsible for interpreting the call, 
retrieving data or doing other data manipulation, and then returning 
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Fig. 10-9 Digital Standard Relational Interface. 


the results in DSRI format. The original example of the DSRI 
recipient was a DEC Rdb database. 

Because DSRI is an open architecture, data access is not restricted 
to DEC-supplied environments. Signal Technology, for example, 
makes Smartstar, a use interface that is DSRI compatible. Embedded 
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SQL (ESQL) programs can also be constructed that use the SQL query 
language to integrate databases with third-generation language 
programs. 

Recipients of DSRI calls are not limited to DEC-supplied software. 
The Smartstar software can access an Rdb database, but it can also 
access a DSRI database furnished by Interbase. DSRI provides a very 
important separation between the use interface and data manipulation 
functions. This allows data to be distributed across the DNA environ- 
ment as well as allowing third-party solutions to work smoothly with 
DEC software. 

The VAXlink and VIDA packages are able to accept standard DSRI 
calls and translate them into the appropriate data access language on 
the target system. The user of Rally asks for data the same way on 
an IMS system as they would on an RdB system. Two levels of 
gateways are provided. In this case a database gateway is built on top 
of an SNA gateway. 

The Data Distributor software is a way of automating the process of 
extracting data from any DSRI database. Data Distributor can query 
one or several DSRI systems and extract data. That data is then com- 
bined into a single RdB database. Data Distributor can be used to 
access an IBM-based data repository and make a copy of the informa- 
tion in an Rdb database. 

Data Distributor does not provide a true distributed database 
capability. Rather, it is able to replicate portions of a database at a 
particular time. This is known as a snapshot of the data. A dis- 
tributed database allows multiple data sources to all be integrated 
into one logical database environment. The user is not aware of the 
location of the data, whereas in Data Distributor, a user has to “point” 
to where the data is located. 


Office Systems Integration 


Both DEC and IBM have constructed fairly elaborate office environ- 
ments. DEC has centered their efforts on the ALL-IN-1 system which 
integrates word processing, menus, calendars, electronic mail, and 
other common utilities. It also includes links into the Message Router 
software which delivers messages in a DECnet environment. 

IBM has two different office environments, one for each of their 
major operating systems. In the MVS environment, IBM has the Dis- 
tributed Office Support System (DISOSS). This software allows docu- 
ments to be filed, retrieved by key word, and sent to other DISOSS 
users. In the VM/CMS operating system, IBM has a functionally 
equivalent system called PROFS. 
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IBM office systems are built on several advanced architectures. 
These architectures supplement the basic SNA functionality and pro- 
vide higher levels of structure. The two fundamental office architec- 
tures are the Document Interchange Architecture and the Document 
Content Architecture. As will be seen later, these architectures cor- 
respond to the envelope and envelope contents that are specified in the 
X.400 message handling systems. 

SNA provides basic data transmission across the network. This has 
been supplemented by a higher level architecture called SNA Distribu- 
tion Services which is message based. SNADS consists of a series of 
distribution service units which accept data for delivery. 

Built on top of SNADS is yet another level of abstraction called the 
Document Interchange Architecture. DIA defines the types of mes- 
sages and their functionality. DIA is used to distribute documents, 
search for documents using search criteria, and to retrieve documents. 
DIA defines two types of nodes. Source/Recipient nodes are able to 
receive and send messages. They correspond to a user agent in X.400 
terminology. | 

Office System Nodes (OSN) are libraries that hold or forward docu- 
ments. A typical example of an implementation of the OSN is the 
Distributed Office Support System (DISOSS). DIA has been widely 
implemented as DISOSS on MVS nodes and as the Personal Services 
Series for PCs, PS/38 and OS/2 systems. 

The contents of those documents is usually defined by the Document 
Content Architecture. DCA has two forms, revisable and final. Both 
RFT (revisable form text) and FFT (Final Form Text) are supported by 
DEC. RFT consists of a subset of functions found in most modern 
word processors. FFT is roughly analogous to the capabilities of an 
Epson dot matrix printer. 

For data output, IBM supports both PostScript and their own ar- 
chitecture called the Intelligent Printer Data Stream. IPDS is con- 
sidered a strategic product and is built on top of an LU6.2 interface. 
IPDS is used almost exclusively on laser printers, such as the 3820 
laser printer. PostScript support is implemented in only a few 
products. 

IPDS requires all layout decisions to be made by the host. In this 
sense, it is not a full fledged language like Postscript. Instead, it is a 
language for representing information on the page in a static fashion. 
The language supports basic multifont text, graphics, images, and bar 
codes. The graphics primitives include basic items such as lines, 
circles, boxes, and shading. The image support includes compression 
algorithms for transmission of data. 

DEC has two families of software called Electronic Document Ex- 
change. EDE with IBM DISOSS links to the IBM DIA/DCA environ- 
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Fig. 10-10 Directory listing of a DISOSS file from VMS. 


ments. Similar functionality to the Wang OIS systems is provided 
with EDE-W. The EDE-W software uses bisynchronous protocols to 
interface with the Wang environment. 

EDE is typically a menu option in the ALL-IN-1 environment. 
Users are able to use the standard library and distribution services 
that are part of IBM’s DISOSS/370 software. This includes the ability 
to search, file, retrieve, and delete documents in the library. Users 
can also send, obtain, show, and cancel document distribution. Figure 
10-10 illustrates DISOSS access from a VMS system. 

The software allows revisable and final form documents to be trans- 
ferred both ways. In fact, with a nonrestrictive search command, it is 
possible to make local copies of DISOSS libraries. It is necessary for 
the IBM system manager to define all the valid users to the DISOSS 
environment. 

Non-ALL-IN-1 users can access the DISOSS environment using 
another package called the DISOSS Document Exchange Facility 
(DDXF). DDXF can only transfer final form documents. DDXF is a 
prerequisite for the EDE DISOSS package. 

Message exchange between the two environments is done using a 
Message Router gateway, which is discussed in more detail in the OSI 
upper layer chapter. Message Router allows a variety of different 
DNA user interfaces to exchange message. For example, users of the 
native VMS mail package can exchange messages with users of the 
ALL-IN-1 mail interface. 

Message router also includes gateways to other messaging environ- 
ments. Gateways exist to MCI Mail and Western Union Easylink sys- 
tem, as well as to the TCP/IP SMTP distribution service. Two 
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gateways exist to the IBM environment, one for SNADS (DISOSS) and 
the other for the PROFS environment. Messaging systems are con- 
sidered in more detail in the chapter on OSI upper layer services. 


Systems Application Architecture 


Both DEC and IBM, by their sheer size, have ended up with many 
different product lines. An early strategic decision by DEC was to 
emphasize the VAX hardware and VMS operating system. When that 
decision was made, it was at great cost to the company. Most of the 
large DEC users at the time of the introduction of the VAX line used 
the DEC 10 and DEC 20 “mainframes.” Reducing support for the 
DECsystems was estimated to have cost DEC $1 billion in lost 
revenues. 

IBM, because they grew so big so early, was unable to consolidate 
into one common architecture. Although the 370 machine architecture 
is the most important one, several different implementations on dif- 
ferent machines have resulted in polluted environments. That means 
that when you want to move from one operating environment to 
another, you have to learn a whole new set of tools. 

Pollution of environments in the IBM world extends significantly 
beyond the underlying machine architectures. On large 370 architec- 
ture machines, there are three different operating systems (MVS, 
DOS/VSE, and VM). On the MVS operating system there are several 
different operating environments, including the Job Entry Subsystem, 
the Time Sharing Option, CICS, and several others. 

There have been two serious implications of multiple hardware and 
software environments. First, IBM has had trouble introducing new 
products because of backward compatibility issues and the fear of 
alienating significant customer bases. Perhaps more important, user 
skills have been very specialized and do not transfer easily to new 
environments. 

Systems Application Architecture is an attempt to bring all the dif- 
ferent operating environments together into a common architecture. 
There are three primary components to SAA: a common user interface, 
a common program interface, and a common communications inter- 
face. Eventually a series of common applications will be developed for 
the different operating systems. 

Because of the magnitude of the differences between the system and 
the amount of entrenched inertia, transition to SAA is a very long- 
term activity. Other major operating environments are undergoing 
similar efforts. These environments include DEC computers and 
various coalitions of Unix-based systems. 
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In the Unix environment, AT&T and Sun have joined on a variety of 
standards that address many similar issues of interchangibility of 
software and skills as SAA. The Open Look standard provides a 
standard “look and feel” for user interfaces. The System V Interface 
Definition (SVID) defines a standard operating system as well as some 
programming interfaces. A binary standard defines a common stand- 
ard for executable images with an orientation toward the Sun- 
developed SPARC architecture. 

Because the Unix community involves many different companies, it 
does not have quite the degree of unanimity presented by IBM execu- 
tives in their discussions of SAA. Splinter groups help form alterna- 
tive standards which are sometimes incorporated into the consensus 
set of de facto standards. Unix is often known as computers by com- 
mittee for this reason. 

DEC is really in the ideal position when it comes to SAA-type is- 
sues. A common operating system and a common programming inter- 
face are already in place for most parts of the operating environment. 
This allows DEC to standardize the user interface. These issues will 
be considered in more detail in Part 5 of this book. 


Common programming interface 


The most important impact of SAA is on program development, since 
programmers see a common interface to the operating system as well 
as a common user interface development environment. Four sets of 
standard interfaces have been defined. Associated with each of these 
programming interfaces are a set of strategic products. 

The three key operating systems that programmers will see are the 
OS/2 extended edition for the PS/2 line, the operating systems on the 
370 architectures, and the OS/400 operating system on the AS/400 
line. SAA includes an attempt to provide a common operating system 
interface for all of the 370-based operating systems. 

Two sets of graphics interfaces are defined. The OS/2 presentation 
manager uses an interface such as Microsoft Windows 286. This con- 
sists of a session manager, a shell help system, and window and filing 
capabilities. On 3270 terminals, the graphics interface uses a graphi- 
cal data display manager which provides similar functionality to 
presentation manager but for single terminals. 

Dialogs, consisting of sets of objects and actions on those objects use 
the ISPF dialog manager for 370 environments and the OS/2 dialog 
manager for workstations. Defining ISPF as a standard dialog 
manager means that the software will migrate from the current 
MVS/TSO environment to include other 370-based operating systems. 
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Programmers will thus be able to count on a standard dialog with the 
user. 

Both of the dialog managers provide an important extension to the 
operating system. Dialogs provide generic fill-in-the-blank methods of 
activating common operating system functions and provide an alterna- 
tive to the usual command interface. Dialog managers are used for 
managing libraries, executing compiler, full-screen editing, managing 
queues, and many other functions. 

Data access in SAA consists of two components. Access to files is 
provided through the use of a distributed data manager. This package 
allows a single file system to accept data from foreign systems on the 
network at the record level. As we’ve seen previously, this is the type 
of functionality that RMS has provided in the DEC world. 

A key part of SAA is that data access is moving from flat files into 
database structures. SQL is defined as the single method of interact- 
ing with database management systems. The SQL may be embedded 
in programs or can be generated by a user interface such as the Query 
Management Facility. 


Common user interface 


The common user interface (CUA) defines a consistent method for in- 
dividuals to interact with programs. The hope is that if every pro- 
gram uses the F1 key as a help key, users will not have to look that 
fact up for any new program. Even more importantly, they will not 
call up the help desk or network manager to obtain that information! 

Users are assumed to have a conceptual model of what a computer 
is and what it does. CUA defines such a conceptual model. For ex- 
amples, the concept that context sensitive help is available at any 
point may be one of the users assumptions about the way a computer 
should work. 

CUA emphasizes a consistent interface to users. Consistency in the 
physical layout of a workstation, in the syntax, and in semantics are 
all stressed. Physical consistency means that the F1 key is always in 
the same place on the keyboard. Syntactical consistency means that 
the F1 key always means HELP. 

Semantic consistency means that a command always does the same 
thing. A common example of semantic inconsistency is the use of EXIT 
and QUIT commands. In some systems QUIT means to leave the ap- 
plication while EXIT means going back one level. In other systems, the 
reverse is true. This provides endless opportunities for steering com- 
mittees to debate semantics. While keeping committees busy may be 
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a desirable goal, it is nice to have the flexibility to have that issue 
decided in advance. 

At the physical level, SAA defines a common keyboard. Many of the 
keys are predefined in functionality. The Fl key is HELP, the END 
key moves the cursor to the end of the current line, and the 
CTRL/END key moves users to the end of data. The mouse is defined 
as being a one-to-three button mouse. If the last two buttons are 
missing, the keyboard must have some key sequence that is equivalent 
to the missing mouse buttons. 

Also included in SAA is support for national languages. Three 
families of languages are defined. Left-to-right languages include 
English and the Latin languages. Right-to-left languages would in- 
clude Hebrew. Finally, double-byte character sets are defined which 
provides supports for large character sets such as Chinese ideograms. 

A screen in SAA may consist of a set of panels. The SAA CUA 
screen presentation is very similar to the Microsoft Windows interface. 
Although the CUA will run on 3270 terminals, it will only allow a 
single window at a time. For this reason, most of the efforts on 
developing the SAA interfaces is oriented around workstations run- 
ning the OS/2 operating system. 

A panel consists of a data area and an action bar. The action bar 
has a series of verbs that the user can point to. Pointing to an action 
verb does not initiate any action. Rather, this leads to a pull down 
menu which then has a series of actions. If there are further choices, 
a pull-down menu action may lead to a pop-up menu with further 
choices. Common icons and symbols are used to indicate the presence 
of further options. 

The body of a panel consists of a series of elements, such as entry or 
selection fields. Selection fields show the user a list and allows them 
to select a particular item. When the pointer rests on an object it is 
highlighted. When the select key on the mouse is activated, the object 
remains highlighted. 

Users interact with the screen using an object/action method. This 
means that users select an object and then select an action against 
that object. This might mean selecting a file and then selecting the 
action of EDIT or DELETE. It might mean selecting a username and 
selecting the action of SEND MESSAGE. The advantage of this method 
is that the programmer is able to present only the valid actions for 
that particular object. This means that mixed types of objects can be 
presented in a single list. 

Selection of actions and objects can use a variety of different techni- 
ques. Scroll bars, action fields, and other techniques are always avail- 
able. In addition, advanced users can use fast path interaction techni- 
ques. A keyboard accelerator ties a menu item to a key sequence. A 


System Network Architecture 305 


mouse accelerator allows specific mouse sequences to accelerate move- 
ments. 


Common communications support 


The CCS portion of the SAA environment allows programmers to see a 
consistent set of communications facilities across token rings, X.25 
networks, and SDLC point-to-point connections. The CCS facilities 
are primarily for the purpose of allowing OS/2 program developers to 
get ready access to facilities throughout the IBM network, particularly 
on 9370, S/370, and AS/400 host systems. 

The key advantage for DEC connectivity of the CCS is that it 
provides a consistent, common interface to non-IBM environments. 
This allows an architecture-based development environment instead of 
trying to connect each individual product to its peer in the other en- 
vironment. 


Summary 


This chapter considered IBM/DEC connectivity by having DNA-based 
gateways emulate the SNA environment. This allows SNA applica- 
tions, such as DISOSS, to communicate with their peers in the DEC 
world. SAA provides a clear architecture for connectivity through 
gateways. 

Several other options exist for connectivity. These include older 
protocols such as Bisynch. Another option is to provide virtual ter- 
minal services via an X.25 link. Terminal emulation provides a non- 
SNA based link to the IBM world. 

A long term trend for both environments is to use international 
standards such as ISDN and OSI. These facilities provide a common 
ground between the two environments. Both DEC and IBM support 
evolving international standards with various degrees of enthusiasm. 
Key users of computer technology insist that vendors provide these 
type of solutions. If both vendors provide the same sets of protocol 
supports in OSI, connectivity becomes a much simpler issue and a 
more stable long term solution. 
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DECnet/OSI and OSI Lower 
Layers 


Overview of DECnet Phase V 


Phase V of DECnet is a significant departure from previous phases of 
the networking architectures that DEC has developed. DECnet/OSI is 
based on the Open Systems Interconnect protocols, a nonproprietary 
architecture, which holds significant promise for multiple vendors 
being able to interconnect with a very high degree of functionality. 

Currently, most systems are able to interconnect. The level of inter- 
connection, however, is very low. Usually, it allows a user of one sys- 
tem to emulate a terminal connected to a remote system. With an 
OSI environment, advanced services such as record level access be- 
come a possibility in a heterogeneous environment. 

In addition to the open nature of the new architecture, several im- 
portant changes have been made. Extremely large networks can be 
formed in a Phase V environment. In a Phase IV network, “only” 
63,000 nodes could be put in the network. In Phase V, the theoretical 
limit is 104°. Since every node in the world is expected to have a 
unique OSI address and the number of nodes is proliferating, this 
large address space is not as unrealistic as it may first seem. 

To illustrate the need for billions and billions of nodes (to 
paraphrase Carl Sagan), think of the evolution of home computer sys- 
tems. It is not unusual to see multiple nodes in a home environment. 
In the future, with the proliferation of microprocessor-based tech- 
nologies, nodes will not be limited to an Apple IIE or PC/AT. Your car 
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computer might communicate with a home central computer system, 
which in turn requests that your robot make you a daiquiri. Each of 
these nodes needs a network address. 

Other important changes in Phase V include significant changes to 
the routing layer. The routing layer in Phase V has been expanded to 
include support for a wider group of data links. The routing algo- 
rithms have been enhanced to provide a greater capability for an in- 
dividual node to determine the state of individual links in the net- 
work. The routing layer has also been expanded to support the OSI 
connectionless network service and addressing methods. 

As in previous phases, DECnet will remain N minus 1 compatible. 
This means that a DECnet network can always coexist with the pre- 
vious version of DECnet. In this case, Phase IV and Phase V net- 
works will be able to coexist. Phase IV applications, such as the DAP- 
speaking File Access Listeners will run on Phase V nodes. These ap- 
plications and other applications based on the OSI applications will be 
available. 

Coexistence will be accomplished through the use of towers. A 
tower is a set of protocols from either the Phase IV or Phase V ar- 
chitectures. A particular packet may travel part of the way down a 
Phase IV protocol stack, then use a Phase V network layer and data 
link. Towers extend from the physical layer all the way up to the 
application layer, and they allow they various combinations of the two 
architectures to cooperate. Although a typical tower would splice 
layers 4 to 7 from one architecture on layers 1 to 3 of the other ar- 
chitecture, it is possible to slice the protocol stack in various places. 


Overview of OSI Lower Layers 


The lower layers of OSI are an interesting mix of protocols. This is 
because they build on existing subnetwork technologies running from 
IEEE 802.3 Ethernet, token rings and token buses to X.25 networks. 
In X.25, a connection-oriented service is provided with some degree of 
data integrity checks. In Ethernet, on the other hand, there is only a 
datagram service with limited error checking. It is the responsibility 
of higher layers to supplement the Ethernet datagram service to pro- 
vide the reliable end-to-end communications needed by the time data 
has passed through the transport layer. 

The OSI model integrates this wide variety of different transmission 
technologies in the network layer. The network layer then provides a 
common set of services to the upper layers of the OSI model. The 
network layer itself is split into several sublayers. The upper sub- 
layer, the subnetwork independent functions, provide routing and 
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Fig. 11-1 Sublayers of the OSI network layer. 


other functions that are needed regardless of the type of subnetwork 
involved. A set of subnetwork independent functions allow the rout- 
ing portion of the network layer to see a common set of network ser- 
vices. 

Underneath the subnetwork-independent functions are subnetwork 
dependent convergence functions. They build on top of the services 
that the subnetwork is able to provide and add enough functionality to 
meet the needs of the upper portions of the network layers. Figure 
11-1 illustrates the sublayers of the network layer. 

The lowest portion of the network layer is the subnetwork access 
procedures. These are access routines to the native capabilities of the 
underlying subnets. In the case of an X.25 subnetwork, this would be 
the establishment of virtual circuits, clearing calls, and similar func- 
tions. In the case of an Ethernet, this would be a simple data trans- 
mit or receive function with a specified Ethernet address. 

The general model for the OSI network service is thus very similar 
to the Internet Protocols examined earlier. Different subnetworks are 
all connected together to form a common network. In the case of the 
Internet Protocols, this network service is only a datagram service—no 
connection-oriented network service is offered. The OSI connectionless 
network service is actually an adaptation of the TCP/IP Internet 
Protocols. In addition to a connectionless network service, the OSI 
protocols also specify a connection oriented network service. 
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Physical Layer 


DECnet Phase V includes support for all the physical media that are 
supported in an Ethernet environment such as normal baseband coax, 
ThinWire coax, twisted pair, broad band, and fiber. In a wide area or 
point-to-point environment, DNA Phase V has support for the RS-232- 
D and RS-423 physical interface standards and for the CCITT V.24, 
V.35 and X.21bis standards. 

Phase V also includes support for the X.21 physical interface stand- 
ard for digital circuit-switched data networks. Although these are not 
especially prevalent in the United States, X.21 networks are popular 
in Europe and Japan. 

X.21 is a set of protocols used to support leased circuits and circuit- 
switched networks. Often, an X.21 circuit is used as a physical con- 
nection in an X.25 packet switched environment. X.21 support in 
DNA Phase V includes a call setup facility, which allows outgoing calls 
to be placed and closed user groups to be established. Criteria can be 
established on which calls will be accepted. Reverse charging is also 
available within this facility. 

A special type of physical interface standard in Phase V of DECnet 
is for dynamically established links. The physical interface standard 
thus includes support for autocall and autoanswer features on 
modems. This service, known as the modem connect service of the 
physical layer, has five parts. 

The call control function allows the physical layer to make an outgo- 
ing call and handle incoming calls. It also allows the ability to clear 
incoming calls. A data transfer function is used to provide a bit- and 
byte-oriented service to the data link layer. 

A named call reference service is used for network management and 
control. By naming a call, it is possible to make this a named entity 
in a Phase V network management environment. This in turns allows 
counters to be established for the call that can be used for security, 
performance, or accounting purposes. 

The modem connect service for dynamic calls also includes a call- 
sharing capability. Normally, a user of the data link service on the 
link would request that the line be cleared upon completion of the 
tasks. For example, the MOP protocols might be used to downline 
load an operating system to a remote node. Upon completion of this 
function, the DDCMP protocols might then need to provide service to 
another user, the DNA routing layer. The call sharing feature allows 
a clear line command to be intercepted at the physical layer and effec- 
tively ignored. | 
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Data Link Support 


Phase V of DECnet supports three different data link protocols. The 
DDCMP and Ethernet protocols have been previously discussed. The 
HDLC data link protocols are a more general model that incorporate 
by reference a variety of subsets including the IEEE logical link con- 
trol and X.25. HDLC includes a variety of subsets conforming to each 
of the different types of data links supported in OSI. 

The high-level data link control (HDLC) is a general model for data 
link services. The general model has several subsets that conform to 
most currently available data links. The LAP B subset corresponds to 
the X.25 data link level. The LAP D subset corresponds to the ISDN 
data link layer. All three LLC classes for local area networks are also 
subsets of HDLC. IBM’s SDLC is also a subset of HDLC, although it 
includes some commands and responses not in the standard. HDLC is 
thus both a specific protocol and a general model; it uses different 
subsets for different types of data link technologies. 

The model is useful because all the different subsets have a fairly 
common interface to upper layers of the network. It thus becomes 
easier to code network layer processes because all the different data 
links fall into the same general class. 

The basic HDLC service is to send a frame from one point to 
another. Each frame on the line is separated by at least one opening 
flag that is unique. The flag is a single byte that has a 0, six 1s, and 
a closing zero. If a string of five 1s is found within the actual data, a 
0 bit is inserted. This is known as bit stuffing and allows the HDLC 
link to provide a transparent data connection while still maintaining 
the ability to control frames. 

A second unique indicator flag in HDLC is the abort flag which con- 
sists of seven consecutive 1s. Again, if the actual data contains that 
information, the HDLC framing process inserts a 0 bit which is 
removed by the other side. 

The actual HDLC packet consists of an address, a control field, data, 
and a frame check sequence. The contents of these frames depends on 
what type of frame is being sent. The frame check sequence (FCS) 
provides error control. It is the responsibility of each HDLC service 
provider to generate and check the FCS to provide an error-free frame 
delivery. 

The default FCS is based on a 16-bit polynomial, although a 32 bit 
sequence is also available. The calculation is based on the contents of 
the address, information, and control fields in the HDLC frame. A 
separate FCS may be contained in the data portion of the frame. 
Usually, integrated circuits are used to perform this calculation. 
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Of course, it is possible for errors to occur at higher levels that 
HDLC can’t find. When a user asks for the wrong file or the session 
layer swaps 2 bytes, it is unreasonable to expect a data link process to 
find that error. The FCS is designed to find bit errors that were intro- 
duced on the physical medium. 

There are two forms of HDLC addressing. A basic address is a 
single byte. The first bit of the address is set to 1, and the next 7 bits 
are the address. This limits the number of nodes on a single HDLC 
link to 128 nodes. This is adequate for X.25 networks, where HDLC is 
used to communicate between a single DCE and a DTE. 

For IEEE or ISDN subnetworks, however, this is not sufficient. 
With an extended address, the first bit is set to 0. The next 7 bits are 
then available for addressing. In addition, a second byte of address 
space can be added. If the first bit of that byte is set to 1, this sig- 
nifies the end of the address space. The use of the MORE bit allows 
14-bit instead of 7-bit addresses. 

HDLC has three different kinds of frames. An information (I) frame 
is used to send sequenced data. A supervisory (S) frame is used to 
send control information such as acknowledgments between HDLC 
processes. An unnumbered information (UI) frame is used to send un- 
acknowledged data. 

The information frame has a control field that consists of a 0 in the 
first bit. This indicates that it is an I frame and not an § or UI frame. 
As in addressing, the I frame control field can be a 1 byte or can use 
an extended version. 

Basic sequence I frames allow up to eight frames to be outstanding 
at any one time. Each frame is sent with a sequence number. Every I 
frame must be acknowledged. The last 7 bits of the control field of an 
I frame have sequence numbers for the outgoing packet and can also 
include a sequence number for the last packet that was received from 
the remote node. Piggybacked ACKs remove the need for sending a S 
frame for every I frame that was sent. 

The first bit of the I frame control field signifies that it is an I 
frame. The next 3 bits are the sequence number of the outgoing pack- 
et. The next 3 bits are the sequence number of the last packet that 
was received. The last bit of the control field is a poll bit. Setting this 
bit is a way to solicit status information from the remote process. 

Extended sequence numbering adds an extra byte for sequence ad- 
dressing. This allows up to 128 frames to be outstanding each way. 
Once the 128th frame is sent, the numbering starts back at 0. This 
modulo 128 sequencing is essential in high-delay environments such 
as a satellite link. 

An S (supervisory) frame is signaled by setting the first 2 bits of the 
control field to 1 and 0. The next 2 bits of the control field indicate 
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the type of supervisory frame. The last 3 bits can contain a sequence 
number for a packet it is acknowledging. Extended sequence number- 
ing is available for S frames. 

S frames can be used for simple acknowledgment, but they are also 
used for flow control and error recovery. S frames can request the 
retransmission of data or can signal that a node is unable to accept 
more data. 

UI frames are used for link establishment and control as well as for 
unacknowledged information. An example of a UI frame is the ex- 
change ID message which is sent when two nodes are able to initialize 
a line dynamically. This message is used when a new node enters a 
LAP D environment. Error reports are also sent using these UI 
frames. 

Two of the main uses for UI frames are for connectionless services 
and for out of band data. In an connection-oriented data link, UI 
frames are used to send expedited data. This allows the UI frames to 
cut in line ahead of a sequence of I frames. UI frames typically carry 
interrupts that signal the remote process to stop processing. 

The other use of the UI frame is in a connectionless environment. 
Ethernet is an example of this. Using unacknowledged transmission 
of frames with no acknowledgment or error recovery is an example of 
the logical link control class 1. LLC 1 corresponds to a minimal sub- 
set of HDLC facilities. 

The two other LLC classes, as well as LAP B and LAP D, use larger 
subsets of the HDLC facilities. LAP B for example, uses a connection- 
oriented subset of HDLC facilities. A link is set up, a series of I 
frames are exchanged and acknowledged, and the connection is discon- 
nected. 


DEC and HDLC 


DNA Phase V uses the extended sequence numbering option of HDLC. 
This extends the number of outstanding frames possible from 7 to 127. 
In certain wide area links such as satellites, it is important to allow a 
fairly high window of outstanding frames. DNA uses the 32-bit CRC 
option of HDLC as a default. The 16-bit option is available as an 
option when connecting to non-DNA environments. 

A special modification to HDLC is used between two DNA stations. 
In this case, the user data field is segmented into two parts. A user 
data length field is inserted right before the true user data. 

Dynamic line configuration is available in DNA Phase V using an 
exchange identification (XID) frame. If the other side of a connection 
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does not support the XID frame, the line will have to be manually 
configured. 

Maintenance data in DNA Phase V is not carried in the normal UI 
packets. This is because these packets are not subject to error correc- 
tion, sequencing, or flow control. Instead, DEC uses the MOP 
protocols on top of HDLC to provide this functionality. 


OSI Network Layer 


OSI in a sense concentrates on providing a different kind of network 
service than DNA does. OSI concentrates on specifying the upper 
layers of the model in great detail. In contrast to DNA, the lower 
layer consists of a general framework that allows a variety of different 
subnetworks to coexist instead of detailed specifications for operation 
of a specific subnet. 

The subnetwork framework in OSI allows the Phase IV routing 
protocols to continue to operate in a Phase V OSI network. OSI does 
not detail how to route information within a subnetwork. Instead, the 
OSI protocols used in Phase V of a network will be used to forward 
data from one subnetwork to another. Other parts of the OSI network 
may be using other routing protocols such as TCP/IP. 

While the lower layers of OSI integrate existing protocol suites, the 
upper layers are a fairly radical departure from networks like DNA. 
A presentation layer is specified in great detail, and applications con- 
sist of a well-defined family of core protocols. File access, virtual ter- 
minals, and messaging systems are just a few examples of the types of 
standardization in the OSI model. 

As in DNA, the lowest three layers of the OSI protocol suites allow 
two end nodes anywhere in a network to communicate. The transport 
and session layer will then use these network services to begin provid- 
ing services to individual users. 

OSI consists of a series of subnetworks, just like the Internet 
Protocol. Each subnetwork may use a different subnet protocol, such 
as ISDN or X.25. A subnetwork makes every node in the subnet look 
as though they are one hop away. In the case of X.25, there may be 
many switching nodes in the path between the nodes, but the virtual 
circuit makes them appear directly connected. 

An JEEE data link with Ethernet or token ring MAC layers, 
provides a similar function. Every node in this LAN environment ap- 
pear to be one hop away. The data link is responsible for managing 
its resources to allow multiple users to share the common media. Fig- 
ure 11-2 shows an ISO network layer packet on an Ethernet subnet- 
work. 
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Fig. 11-2 Contents of an OSI IP packet on Ethernet 


OSI links subnetworks together into one common network. This 
network layer may offer either connection oriented or connectionless 
service. If X.25 is the subnetwork, it is very easy to offer a connec- 
tion-oriented network service. This is because the subnet is already 
providing that functionality. 

In the case of an Ethernet MAC layer, on the other hand, offering a 
connection-oriented network service would require the software in the 
network layer to provide sequencing, error detection, and other ser- 
vices. While the network layer could provide those services, another 
option is to offer a connectionless network service (CLNS). It would 
then be the responsibility of the transport layer to provide the connec- 
tion-oriented service. 

As can be seen, either the subnet, the network, or the transport 
service provider can make the connection-oriented link between two 
processes. If a lower layer cannot provide that service, it is ultimately 
up to the transport layer to provide it. 

When the entire connection-oriented service is provided at a subnet- 
work layer, as in the case of an X.25-based environment, it is possible 
for the network and transport layers to be essentially null. All the 
functionality needed is already provided in the lower layers of the 
protocol stack. 

Other times, the network layer is essentially null. When the sub- 
network can provide an end to end data link, there is no need for 
routing. This is the case when two nodes are connected to a similar or 
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extended Ethernet. In this case, a CLNS service is layered over the 
Ethernet. The transport layer can provide sequencing and error detec- 
tion and turn the CLNS into a connection-oriented service. 

A connectionless service all the way through the session layer is an 
optional service in OSI used for request response systems. This might 
be the case in a network consisting of large numbers of ATM machines 
communicating to a central bank. Rather than keep circuits open, it 
might be more efficient to just send self-identifying datagrams through 
the network. 

A connectionless service is also useful for devices that don’t have the 
resources necessary to keep sessions open. A programmable controller 
in a factory is an example of this. As will be seen, the manufacturing 
messaging service is an example of an OSI protocol that uses an es- 
sentially null session, has transport and network layers, and com- 
municates directly with the subnetwork. 


Phase V CLNS Network Service 


Routing in Phase V is based on the connectionless network service 
(CLNS). This provides a datagram service which is similar to the 
Phase IV routing service. Messages in a CLNS environment can be 
up to 64 kbytes long. Each routing node in Phase V is responsible for 
knowing all its neighbors and the cost for each link. 

An enhancement to Phase V is the imposition of a further level in 
the hierarchy. Areas in a DECnet are combined together to form a 
routing domain. Several routing domains can exist in a single 
DECnet. It is possible for some of those routing domains to be non- 
DNA environments. 

Routing domains are in turn collected into a single administrative 
domain. An important feature of Phase V is that other routing 
domains and administrative domains are all available to other nodes. 
The CLNS network service, based on the DOD IP protocols, is used to 
reach other routing domains. That routing domain then uses a 
domain-specific routing algorithm to reach the final destination. 

The routing layer is able to use several different subnetworks. In a 
broadcast environment, the network layer is able to use Ethernet as a 
method for getting data between two nodes. In a nonbroadcast en- 
vironment, the links can be either permanent or dynamic. A per- 
manent link is used as in a Phase IV environment and has a cost 
associated with it. This permanent link might be a DDCMP data link 
or it might be a permanent virtual circuit in X.25. 

Dynamic links allow a point-to-point configuration to be added on 
demand. The dynamic link can be static, meaning that it is manually 


DECnet/OSI and OSI Lower Layers 317 


brought up and meant to be permanently available. An example of 
this would be an X.21 link. Another example is dynamic connection 
management. The routing layer is able establish a link upon receipt 
of traffic. The link is then brought back down when a timer expires. 

There are two pieces to the DNA Phase V network layer. A subnet- 
work independent portion is used to provide much of the logical 
functionality. These commands include routing decisions, segmenta- 
tion and reassembly, lifetime control, and congestion control. 

Routing decisions are made based on the availability of subnetwork 
functions. As discussed, the decision within a DNA routing domain is 
made based on costs and hops. Because of the link state algorithm, 
this decision can be made in a more sophisticated fashion. Inter- 
domain routing decisions are made by finding the boundary level 2 
router that interacts with the two different environments. 

Two kinds of source routing can be specified. Partial source routing 
gives a list of hosts that must be visited to route the packet. Between 
any two of the hosts specified, the packet may take any route that is 
available even if this means visiting unspecified hosts. 

Complete source routing specifies exactly which hosts are to be 
visited. No other hosts may receive the packet if they are not 
specified in the source routing address. Complete source routing is 
used for security purposes to only visit trusted hosts. Partial source 
routing is used to make sure that a packet gets delivered even if inter- 
mediate hosts do not know about the location of the final destination 
address. 


Phase V Link State Routing 


The Phase IV routing tables consist of a list of nodes that are reach- 
able and the intermediate node to send a packet to for a particular 
path to the end node. Each path has a cost associated with it. Al- 
though the calculation of the number of hops and costs is based on the 
data links, no information about this is contained in the routing table. 
The routing table is thus a summary table in Phase IV. 

In Phase IV routing control messages, each node transmits it’s sum- 
mary table to the next. If one router notifies the next router that it 
can reach node A with three hops, the next router assumes that it can 
reach node A with a total of four hops. Because there are alternative 
paths to each node and because routers summarize the routing infor- 
mation, there may be several different interpretations of how far away 
a particular node is. It thus takes several messages for the network to 
stabilize after a configuration change. With a large area and many 
level 1 routers, it is possible for a significant portion of the network 
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bandwidth to be used on routing control messages until the situation 
stabilizes. 

DNA Phase V has a subnetwork routing algorithm based on link 
states. This means that each nodes periodically transmits the status 
of all adjacent links. Nodes thus receive basic routing data instead of 
summary information. Each node then proceeds to summarize this 
information for its own routing decisions. Since nodes present basic 
data on the network instead of their view of what the network looks 
like, it takes far fewer messages to stabilize a configuration. 

An important implication of a link state algorithm is that it lays the 
groundwork for sophisticated adaptive routing schemes. Since data on 
each link is available, it is possible for nodes to begin making routing 
decisions based on link saturation. This is not available in initial 
Phase V releases, but the basic architectural change permits expan- 
sion into these more sophisticated routing environments in the future. 

Link state packets are sent out periodically by each routing node to 
each adjacent neighbor that is also a router. The LSP contains a se- 
quence number. The receiving node compares the LSP it just received 
to current one it has. If the received one is newer, the node updates 
its routing database. It then forwards the LSP to all other neighbors. 
In this fashion, LSPs are quickly propagated among routing nodes. 

If the LSP received was older than the one the node currently has, 
the node sends the newer LSP back out to the receiving line. LSPs 
contain sequence numbers to help determine the age of each packet. 
These packets also have an age field which signifies when the infor- 
mation should be deleted from routing databases. 

The LSP process occurs simply within the DNA level 1 subdomain. 
Routing in between areas and in between administrative domains is 
done using the static CLNS routing scheme based on IP routing 
tables. The process of determining how to route between these areas 
is specified in a particular administrative domain but is not necessari- 
ly specified in between administrative domains. This is why source 
routing is provided for packets that are forced to travel extensively 
over the internet, such as electronic mail messages. 


Other Network Layer Functions 
The Phase V network layer includes several other functions: 


=» Segmentation and reassembly 
w Lifetime and congestion control 
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The segmentation and reassembly function is used to reduce a mes- 
sage from the transport layer into segments that are small enough for 
transmission over the relevant subnetwork. In the case of an Ether- 
net, the 64,000-byte network message would be segmented into 1500- 
byte pieces. Segmentation may occur once the packet has already 
visited several nodes if the next subnetwork has a smaller size. Once 
a packet has been segmented, it is not reassembled until it reaches its 
eventual destination. 

The lifetime and congestion control functions are used to reduce net- 
work saturation and other transient load problems. A time to live 
field is decremented by 1 for every node the packet visits. Once the 
time to live field reaches 1, the packet is summarily executed. The 
assumption behind this function is that once a packet has visited 63 
nodes, it is clearly lost. The transport layer at the eventual destina- 
tion will have surely requested retransmission, and it is therefore 
more economical of network resources to discard this packet. 

The congestion control function is used to inform transport layer 
users of the network service about network congestion. Presumably, a 
well-behaved transport service will then reduce its transmissions in 
the interest of total network throughput. If any node on the network 
receives a packet and its queue of packets has reached a certain 
threshold, it sets a congestion experienced bit in the NPDU. 


Network Addresses 


Addresses in Phase V of DECnet use the ISO addressing scheme 
which is designed to provide support for world wide addresses. This 
address space is actually a superset of existing addressing schemes, 
such as the X.121 public data network addresses (telex) or the E.163 
public switched telephone network numbers. 

ISO addresses are based on a domain system. The X.121 address 
space is one example of a domain. The network address consists of an 
initial domain part and a domain specific part. The initial domain 
part (IDP) starts with an authority and format identifier which 
specifies which domain is being referenced. Following the AFI is an 
initial domain identifier (IDI). The IDI might be a country code or 
other high-level part of the address space. The domain specific part of 
the address depends on the type of domain chosen. 

The domain-specific part of a DNA routing domain consists of three 
separate fields. An area designation is contained in the first 2 bytes. 
This important architectural change allows significantly more than the 
Phase IV limit of 63 areas in a single DECnet. The area address is 
followed by a 6-byte local identification. 
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An important new feature of Phase V is autoconfiguration. Each 
DNA node has a unique 6-byte node ID. This address is presumed to 
be unique even across areas. The last byte is a selection ID which 
indicates who the user of this network service is (i.e., the routing con- 
trol module or a particular transport layer). End nodes in DNA will 
automatically find their nearest router and configure themselves to be 
part of that area. In addition, the selection field is automatically con- 
figured. 

The automatic configuration feature means that new nodes can be 
added to the network without manual intervention at the network 
layer. The distributed naming service allows new logical node names 
to join the network and register themselves with a nameserver. 
Together, these two capabilities mean that the only addresses that 
need be manually configured are routers. 


Transport and Network Layer Service Interaction 


The network and transport layers are both able to provide connection- 
oriented services. However, it is the ultimate responsibility of the 
transport layer to provide reliable end-to-end communications. The 
transport layer is able to issue facility requests to the network layer 
that contain queries of the current level of service available. 

One type of information the transport layer needs to know is the 
ability of the network layer to provide congestion control. This in- 
fluences the need for the transport layer to aggressively monitor tran- 
sit delay in order to adjust the window of outstanding packets. 

Another important type of information is the sequence preservation 
probability. This is the probability that packets will be preserved in 
the sequence they were submitted. The transport layer will need a 
larger holding area buffer if packets frequently arrive out of sequence. 

A third facility report the transport layer may request is the maxi- 
mum lifetime of data units submitted to the network layer. The 
transport layer will also usually monitor actual round-trip transit 
delays for packet acknowledgment. Together, these parameters enable 
the transport layer to adjust expiration timers. 
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OSI Upper-Level Protocols 


Overview of OSI Upper Layers 


While the OSI lower layers are a mixture of existing protocols, the 
definitions of the upper layers are more consistent. This is because 
the network and lower layers need to accommodate a range of existing 
networks and physical media since the OSI protocol suite was 
developed after many current technologies were already in place. 
Many of these existing networks were already standardized and the 
ISO working groups decided to build on existing technology. 

As in DNA Phase IV, the next two layers of the network form a 
bridge to the upper layers of the network. The session and transport 
layers provide a reliable end to end delivery service for data and form 
the bridge to the users of the network. 

The OSI model, in contrast to DNA Phase IV, explicitly defines the 
services of a presentation layer. This is because in an OSI environ- 
ment there are heterogeneous systems communicating. The presenta- 
tion layer can handle issues such as transferring the representation of 
data from ASCII to EBCDIC or encrypting and decrypting data. 

The applications layer of OSI defines a series of services. A set of 
Common Application Service Entities allows two applications to form 
an association. Services, such as File Transfer Access and Manage- 
ment (FTAM), then use that association to exchange information. 

A particularly important set of services is the X.400 message han- 
dling protocols. X.400 is similar to other message-handling systems, 
such as SNADS in the IBM environment. X.400 replaces a variety of 
different proprietary systems with an international standard for mes- 
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sage handling. X.400 services form the core of DEC’s message han- 
dling strategy. 


Transport Layer Protocols 


The Transport Protocols define five types of end-to-end connectivity. 
The most sophisticated class, TP4, provides end-to-end error detection 
and recovery. The TPO class, on the other hand, is almost a null 
transport layer. TPO protocols will only work on top of network layers 
that provide a connection-oriented service with error detection. Any 
errors that get by the network layer services have to be dealt with 
specifically by the application code. 
The five classes of service are: 


TP class 0: Simple class 

TP class 1: Basic error recovery 

TP class 2: Multiplexing with limited error recovery 

TP class 3: Multiplexing with error recovery 

TP class 4: Multiplexing with error detection and recovery 


The most basic class, TPO is provided to give backward compatibility 
with current Teletex systems and X.400 messaging environments. 
This class requires a reliable underlying network connection, such as 
an X.25 virtual circuit. The transport layer data unit size must be 
smaller than the network layer packet size because TPO is not able to 
segment large data units. Likewise, TPO is unable to concatenate 
small data units together before handing them to the network layer to 
provide higher efficiency. 

Because TPO assumes a reliable underlying network connection, this 
protocol class makes no provision for reassignment of a network link 
after failure. This means that the application software must handle 
all error recovery mechanisms. A messaging system, for example, 
would need to keep a copy of the current message cached in case the 
transport layer notifies it that message delivery failed. 

The next class, TP1, adds a basic error recovery function. The TP1 
module assumes that the underlying network will detect errors and 
signal it when they occur. The TP1 module is then able to reassign 
the transport session to a different network connection. TP1 also adds 
an expedited data service, if the underlying network provides that ser- 
vice also. Like TPO, TP1 does not provide any multiplexing 
capabilities. Only one transport stream may be used. This means 
that a single X.25 permanent virtual circuit would be dedicated to a 
single session at a time. This is not a problem if you have many vir- 
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tual circuits, but a single T1 line might provide more bandwidth than 
the manager would want to dedicate to a single user. 

TP class 2 adds a multiplexing capability to class 1. Class 2 does 
not provide error recovery capabilities and thus assumes that the net- 
work layer provides the functionality to both detect and recover from 
errors. TP2 then provides a limited notification service to users of the 
transport service. TP2 is used when bandwidth needs to be shared 
among multiple users and the underlying network condition is of fairly 
high quality. 

TP class 3 provides both error recovery and multiplexing capability, 
combining the functionality of classes 1 and 2. Class 4 adds consider- 
ably to that functionality by providing an error detection as well as 
recovery capability. TP4 also allows a single transport connection to 
be split over multiple lines. Error detection is in the form of out-of-se- 
quence data units or checksum failures. TP4 users are assured of an 
error-free stream of data. Note that error free is a relative term—the 
transport layer can only detect bit failures and out of sequence data 
units. Access to a secure file would be an error that would have to be 
detected at a higher layer, for example in the validation mechanism of 
a file access protocol. 

DECnet Phase V is built primarily upon the TP4 transport services. 
TPO and TP2 are provided in Phase V as a means to interact with 
non-DNA systems, such as a public X.400 message-handling system. 
Figures 12-1 and 12-2 show TP4 traffic on an Ethernet. 

To begin a session, the user of the transport service specifies the 
address of the remote user (the remote transport service access point, 
or TSAP), the need for expedited data, and various QOS targets. The 
transport service than returns success or rejection indicators. Rejec- 
tion could be at the local transport service if it is unable to meet the 
user requirements. Alternatively, the remote transport service user 
might reject the session because of incompatible QOS requirements or 
congestion. Finally, the remote TSAP might reject the connection, 
possibly because of access violations or other security considerations. 

A transport connection has three phases. Connection establishment 
involves negotiating the appropriate transport classes and parameters 
that meet the transport service users’ desired QOS goals. The data 
transfer phase of a connection provides reliable data transfer, possibly 
with flow control and expedited data services. Finally, the connection 
is released. 

An addendum to the TP definition provides for a connectionless 
transport service, although in DNA Phase V, connectionless services 
can be supported at the network layer and not at the transport layer. 
A connectionless transport service has only one phase: data transfer. 
A UNITDATA command is sent down from the TS access point. This 
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Fig. 12-1 TP4 connection request. 
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Fig. 12-2 TP4 traffic on Ethernet. 
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UNITDATA data unit specifies an address, data and QOS parameters. 
QOS indicators include transit delay, a residual error probability, and 
security protection. . 

The connectionless transport service definition might use a connec- 
tion-oriented network service. The transport service might release 
that connection immediately after sending the connectionless 
transport data. This means there is a potential for the disconnect 
command to overtake the data unit at the remote side. The data unit 
would then be discarded since it belonged to an inoperative network 
connection. To prevent this situation, CLNS transport services run- 
ning on a CONS network service are required to let a timer expire 
before they release the connection. 


Quality of service 


The transport service user, usually the session layer module, is able to 
specify a target quality of service for a particular transport connection. 
Based on these QOS parameters, the transport layer is then able to 
choose an appropriate network layer over which to route that traffic. 

Quality of service can be expressed in terms of goals or in 
parameters meant to achieve those goals. Example of QOS goals are 
high throughput, low delay, and low error rates. Note that several of 
these goals are incompatible. A satellite link might provide very high 
throughput, but it does so at the expense of a very high delay factor. 
A low error rate is probably not very compatible with high throughput, 
since high throughput implies large block sizes which make error 
recovery more difficult. 

Specific parameters can also be specified for a desired quality of 
service. Line speeds, target bit and block error rates, and data unit or 
window size are all parameters that help influence the quality of ser- 
vice. A large data unit size might provide higher bandwidth. A large 
window size means that many data units can be outstanding and un- 
acknowledged, permitting higher throughput. 

A very important quality of service indicator is a security require- 
ment (although this indicator is not provided for in the ISO transport 
layer specification). A high security requirement objective might re- 
quire that the network connection use complete source routing to 
prevent entrusted nodes from receiving sensitive data. A more severe 
security requirement might require that every data link provide sup- 
port for data encryption. 
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Data transfer phase 


The data transfer phase begins with the acceptance of a data unit 
from the transport service access point (TSAP). The transport layer 
can accept an arbitrary amount of data. If the data size is bigger than 
the underlying network connection can handle, it is segmented into 
several pieces. The opposite of segmentation is concatenation where 
several TSAP data units are concatenated into one transport protocol 
data unit (TPDU). 

Once a TPDU is sent to the network layer, the transport service 
retains a copy of it. The transport service (TP4) also sets a timer at 
that time. A TPDU acknowledgment must be received before the data 
unit is discarded so that the transport service can retransmit the data 
unit if necessary. 

A special kind of data unit is the expedited data unit. Some net- 
work service providers have an expedited data facility that has a 
separate queue from the normal data. Expedited data at this level 
can only include 16 bytes of user data and only one data unit of ex- 
pedited data can be outstanding at one time. This service is typically 
used for interrupts and status messages. 

If an acknowledgment of the data unit is not received before the 
timer expires or if a negative acknowledgment is received, the 
transport TP4 service retransmits the data unit. It is possible that 
the TPDU was received at the remote end and that an ACK was sent 
out but was delayed on route because of congestion. It is important 
for the timer value to be properly set to avoid overloading an already 
congested network with unnecessary retransmits. TP4 makes the 
transport service timer a function of the estimated round-trip delay on 
the network. ‘This estimate is maintained and updated for each 
transport connection so that the transport service remains responsive 
to different users. 

Another flow control mechanism employed at the transport layer is 
a credit mechanism. If the service has 0 credits, it may not send a 
normal data unit. Expedited data, on the other hand, can always be 
sent, but only one packet may be unacknowledged at any one time. 
Credits are established at the beginning of a session and are subject to 
negotiation during the connection phase. 

In some configurations, a transport service provider might provide 
credits to a large number of different connections under the assump- 
tion that they will stay idle. Like a bank, if all users activate at the 
same time, the transport service cannot meet its obligations. To meet 
this situation, a transport service may issue a credit reduction, which 
is somewhat similar to the source quench requests in the Internet 
Protocol. Immediately after the new policy is announced by the 
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transport service provider, may be implemented. This means that a 
foreign node may have transmitted a batch of data assuming it knew 
the credit policy. The receiving node (the source of the credit reduc- 
tion) then throws data out that violates the new policy. 

DNA Phase V uses two additional algorithms for congestion- 
avoidance. Some network connections provide a congestion ex- 
perienced bit. This is used whenever a data unit visits a node that 
has a queue greater than some architecturally defined number. The 
transport service then voluntarily reduces the size of its window below 
the available allotment to help reduce network congestion. 

A second voluntary flow control mechanism is employed whenever 
messages are lost on a connection. It is assumed that message loss is 
an indicator of serious congestion. The receiving node again voluntari- 
ly reduces its credit window below that it is entitled too. 

All data sent by the transport service can include a checksum cal- 
culation. The use of a checksum is mandatory in all classes of service 
for connection establishment and termination. The use of a checksum 
is also optionally used in TP4 sessions. It is assumed that the data 
link and network layers do some error checking. The checksum is thus 
not really designed to trap bit errors. On the other hand, missing 
bytes are easily caught at this level. 


DEC transport layer software 


The VAX OSI Transport Service (VOTS) provides both the network 
and transport services of OSI. At the network layer, VOTS provides a 
CLNS protocol which is equivalent to the TCP/IP Internet Protocol. 
At the transport layer, VOTS provides the ISO connection oriented 
transport service for classes 0, 2 and 4. 

The transport interface can be used in both a wide area and a local 
area environment. In a local area environment, such as the token bus 
MAP network, the network layer is essentially null because the sub- 
network is able to provide the functionality needed. 

In a wide area environment, the Internet Protocol is used but only 
as an end system. This means that the VOTS software cannot be used 
to route IP traffic through on behalf of other nodes. Even in the wide 
area environment, the IP service is null when both nodes are part of 
the same X.25 subnetwork. It is only when going among subnets that 
the IP software is really activated. 

The transport software supports a maximum transport PDU of 8192 
bytes in a wide area environment and 2048 bytes in a local area en- 
vironment. The TPDUs may be sent with or without checksums. The 
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transport layer will work with subnetworks that do not offer expedited 
data transfer, although this will lead to a sacrifice in performance. 

At the network layer, VOTS provides a limited lifetime control func- 
tion. This means that VOTS does not check the lifetime control over 
an incoming data unit but is able to properly initialize that value in 
outgoing data units. Since VOTS is merely a transition vehicle, this is 
not really a major limitation. Most transition OSI environments will 
consist of two subnets that are directly connected and there is thus no 
need to control the behavior of intermediate routing nodes. 

Because VOTS provides end system implementation of IP, the rout- 
ing function is based on a static database. The routing database is 
entered by the network manager and consists of a list of nodes that 
are available and which gateway is the next hop needed to reach that 
node. Users are of course free to specify complete or partial source 
routing to augment the routing database. 

Error control functions in VOTS are fairly standard. Checksums 
can be enable or disabled. The network manager can specify that out- 
going data units have the proper bit field set to inform remote nodes 
to notify the sender in case of errors. Likewise, VOTS is able to 
prepare a proper IP error packet in case of incoming errors. Errors 
generated can be logged. 


Session Layer Protocols 


The session layer provides a transition from worrying about transfer- 
ring data on the network to the functions of using that data effective- 
ly. The session layer can be a very simple function of setting and 
releasing a connection. 

The user of the session service sets up a session by sending down a 
S-CONNECT message. This message specifies a session identifier 
provided by the user. This would be used by a multithreaded applica- 
tion that was providing services to many different users. It might also 
be used by an application that wished to continue a particular a ses- 
sion at a later point in time, possibly because of an error condition. 

The session user also specifies the address of the remote user ap- 
plication it wishes to communicate with. Currently, the session layer 
specification says that a session connection confirmation must be sent 
by the same application that receives the session connection request. 
This means that call redirection and generic services are not sup- 
ported. 

The session layer provides two major services to the upper layers: 
synchronization points and session control tokens. Major synchroniza- 
tion points help identify a particular activity, such as the opening and 
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data transfer of a file within the FTAM service. A minor synchroniza- 
tion point is used to identify particular points in that activity, such as 
the transfer of a few blocks of data within the file transfer regime. 

The purpose of a synchronization point is to “push” all remaining 
data for an activity through the network. This allows the remote user 
to finish that particular activity. All data after the synchronization 
point is thus destined for the new activity. This is important since the 
next activity might involve a new program or subprocess that is un- 
able to deal with the previous data (or that if it receives data from 
another context it misinterprets it). 

A minor sync point is accomplished by sending sync messages down 
both logical data channels: normal and expedited. A major sync point 
ensures that both sides agree by requiring the other side to respond 
with acknowledgments on both channels. For a major sync point, the 
sending side does not send any data until both ACKs are received. 

Tokens allow several services, including the imposition of a half- 
duplex mode of operation on a full-duplex transport layer. In order to 
transmit a message, the session layer must be in possession of the 
applicable token. There are four kinds of tokens: 


. Data send 

. Connection release 

. Minor synchronization points 
. Major synchronization points 


m GC db 


Tokens can be traded with each message or can be permanently in 
the possession of one side. Expedited data does not need a token to 
transmit but as in the lower layers, only one expedited data data unit 
can be outstanding at one time. Although it would be impossible to 
convince most users, repeatedly pressing the interrupt key on a 
remote connection does no good if only one data unit of expedited data 
can be outstanding at one time. This means that the queue of inter- 
rupts built up from the user impatiently repeating that sequence takes 
a good deal of time to clear: 16 interrupts means 16 round-trip sequen- 
ces before the final one is delivered and normal processing can 
resume. It should be noted that most OSI implementors would not 
allow this situation to occur and would only process one interrupt re- 
quest at a time. 

If a node does not posses a token and wishes to send data, it may 
issue a S-TOKEN-PLEASE request, which may also contain up to 256 
bytes of user data. The other side is of course free to refuse to give up 
the token. 

The VAX OSI Applications Kernel (VOSAK) consists of a series of 
procedures contained in a programing library. VOSAK is used by 
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higher-level applications, such as X.400 gateway software. VOSAK 
consists of a privileged sharable image that can be linked into users’ 
programs. VOSAK assumes the presence of the VOTS service at the 
transport layer. This is a fairly complete session layer implementa- 
tion including support for activity management, full-and half-duplex 
sessions, and expedited data channels. 


Presentation Layer 


The DNA Phase IV environment has no formal definition of a presen- 
tation layer. Each application defines not only the semantics of its 
operations but the syntax for those operations. DAP, for example, 
defines a variety of commands for accessing indexed files. This is a 
semantic operation. DAP also signifies the representation of that data 
by specifying a particular packet format for that data. 

The OSI environment explicitly separates the semantic nature of an 
operation from the transfer representation of that data. The presenta- 
tion layer also has some functionality that DNA has in the lower 
layers. This is the low-level representation of data. Because DNA is a 
relatively homogeneous environment, issues like bit ordering do not 
arise. Bit ordering is the issue of whether the least significant bit in a 
byte is the first or the last bit received. Sun Workstations, for ex- 
ample, use a different bit ordering scheme than VAX workstations. 
This means that even if both sides agree on ASCII as the data repre- 
sentation for text, they must further agree on the proper bit ordering. 

The OSI presentation layer is based on the notion of an abstract 
syntax. The abstract syntax is a definition of a series of data struc- 
tures; it defines elements such as booleans or character strings. 

Associated with the abstract syntax are a series of available transfer 
representations. A transfer representation might include encryption 
or compression options. It could deal with ASCII versus EBCIDIC rep- 
resentations of data. Figure 12-3 illustrates the abstract and transfer 
representations of data. 

The abstract syntax notation (ASN) is a method for representing 
complex data structures. A file, for example, might be a data struc- 
ture composed of records. Records are composed of a repeated set of 
characters terminated by a particular end of record terminator. The 
application (FTAM in this case) could then send a “files,” as opposed to 
a “records,” across the network and the remote FTAM user would 
know that it was getting a file instead of a record. 

The current ASN is ASN.1, which is based on a variety of protocols 
developed by the CCITT and ISO. ASN.1 is an extremely powerful 
language, similar to Pascal in notation. Primitive values in ASN.1 
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Fig. 12-3 Presentation layer encoding. 
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include booleans, integers, characters, and other constructs. These 
primitives may then be combined into data structures using a series of 
building blocks. 

An example of a building block is a sequence. This is an ordered 
group of lower level structures. We can thus define a protocol data 
unit in ASN.1 as a data structure. Another building block is a set, 
which is an unordered set of lower level structures. Finally, a choice 
is one particular item out of a range of valid choices. 

An example of a choice data structure would be to define a priority 
level in a PDU definition. This might have a definition as follows: 


priority CHOICE 

{ high (0), 
medium (1), 

low (2) } 
DEFAULT {medium} 


This definition has two advantages. The applications can refer to 
high or low security and not worry about how to represent that value 
to the other side. It can also not refer to priority levels at all and the 
other side would know that the default was medium. 

ASN.1 also provides a set of built-in structures. Time and date are 
both defined, for example. This means that an application has only to 
be able to read time and date using the OSI standard and no longer 
needs to support 35 different time and date formats Another built-in 
data type is the visible string—the set of printable characters. An 
electronic mail message can be defined as a set of characters of type 
VISIBLE_STRING. 

The encoding rules, or transfer representations, specify how to rep- 
resent abstract syntaxes for transfer over the network. A variety of 
transfer representations might be defined for use with a particular 
abstract syntax. Together, the combination of an abstract syntax and 
a transfer representation form a presentation context. 

Once in encoded form, the data sent over the network consists of a 
1-byte type identifier, a length indicator, and the actual data. The 
type identifier includes a type class and a 5-bit ID code. The verbose 
ASN syntax is thus reduced to a series of low-level information, which 
is then optionally encrypted or compressed. 

The presentation layer allows a set of presentation contexts to be 
available. One context might be used for the transfer of graphic infor- 
mation (a series of compressed bit strings) while another context 
would be used for the transfer of textual information (a series of un- 
compressed values of type VISIBLE_STRING). 
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Abstract syntax definitions for major applications are named and 
registered by either the ISO or CCITT. Examples are the syntaxes for 
message handling and file transfer. Other ASN.1 syntaxes are being 
developed by other organizations. For example, the American Nation- 
al Standards Institute is developing an ASN syntax for use in trans- 
ferring standard data dictionary elements between cooperating instan- 
ces of the Information Resources Dictionary System (IRDS), a data 
dictionary definition. 


Application Layer Overview 


The applications layer provides a series of services that will be used 
by other programs that require open network access. A set of common 
application facilities, Known as the common application service ele- 
ments, provide an application-to-application association. The CASE 
facilities can be used by all different types of users of the network, 
ranging from robots to messaging systems to virtual terminal services. 

A series of other services is used for specialized functions. Three 
basic services give access to files (FTAM), remote processing (JTM), 
and virtual terminals (VT). Many other services are defined in the 
OSI model that builds on the basic services. For example, building on 
top of CASE and other services are remote database access services. 

The users of the application layer services are truly user programs. 
This is in contrast to all the lower layers, where a user is just the next 
layer up. The user of the network layer is the transport layer, the 
user of the transport layer, the session layer, and so on. Here, the 
users of application services are actually programmers. Programmers 
use these basic services, in the form of library calls, along with other 
services, such as screen painting utilities or mathematical program- 
ming libraries. 


CASE Facilities 


The application layer defines two types of common application service 
elements. The association control service elements are used by two 
applications that wish to establish or terminate an application associa- 
tion. The commitment, concurrency, and recovery facilities are 
facilities used to allow applications to recover to a previously agreed 
point. 

The ACSE service elements are used to associate, release or abort a 
session. Level 1 of the ACSE definition allows only a static associa- 
tion. Level 2 allows application switching, so one particular associa- 
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tion is used by multiple applications. With a level 1 ACSE definition, 
multiple semantic contexts require multiple application associations. 

The association commands might seem a little wasteful, given the 
presence of similar functions at the session and transport layers and 
the establishment of a presentation context (which implies a session). 
All of these requests are embedded into one message to prevent a was- 
teful exchange of data units at startup time. 

The commitment, concurrency, and recovery (CCR) facilities are 
similar to the database two-phase commit protocols used in a dis- 
tributed transaction processing environment. CCR is an optional 
facility in some applications (such as FTAM) and is required in others 
(such as JTM). 

CCR allows multiple nodes to cooperate in a transaction processing 
environment. A example of this environment is a distributed banking 
application. Checking account balances are kept on one MicroVAX 
(this is a small bank) and saving account balances are kept on a 
separate one. Users log onto a third MicroVAX, which serves as the 
automatic teller machine (ATM). When a user asks to have money 
transferred from savings to checking, the ATM must check to see if 
the savings balance is adequate, then deduct the amount from savings 
and add it to checking. If the network goes down after the deduction 
from savings but before the addition to checking, the user will not be 
especially enthused about the situation. 

CCR ensures consistency by doing distributed transactions in two 
phases. First, each node is told to PREPARE a particular transaction. 
This means that the foreign node is prepared to either do that par- 
ticular transaction or bring the data back to its previous state. The 
foreign node also guarantees that no other user will perform an incom- 
patible action on that resource. Figure 12-4 illustrates the CCR mes- 
sage exchange. 

A node acknowledges a PREPARE request with either a READY or 
REFUSE message. Once READY messages have been received from all 
nodes on the network, the ATM would then send out COMMIT mes- 
sages to all nodes. Once acknowledgments of each of those COMMIT 
operations is received, the ATM has a fairly high assurance that all 
transactions occurred. 

It is possible that the ATM would issue a ROLLBACK command in- 
stead of a COMMIT. Perhaps the checking account would receive a 
ROLLBACK if a REFUSE message was received from the savings ac- 
count. It is a responsibility of the CCR remote node to return the 
resources to their previous state. 

One possible situation is that the ATM PREPARES several transac- 
tions and then crashes. In that case, it is unreasonable for the remote 
node to reserve scarce resources indefinitely, and, at some point, it 
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Fig. 12-4 CCR message exchange. 


will have to decide whether to commit or roll back that particular 
transaction. The beginning of a CCR sequence allows the requesting 
node to specify what to do in case of a node failure. The foreign node 
is instructed how long to reserve the resources and which action to 
take upon a time-out. As with most OSI parameters, the two nodes 
might disagree and then they would need to negotiate these 
parameters. 
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File Transfer, Access, and Management 


A wide variety of file access mechanisms are available in networks. 
The FTP service, discussed previously in the chapter on TCP/IP, al- 
lows the bulk transfer of data among a large variety of systems. The 
DNA DAP services provide a high degree of functionality, but at the 
cost of performance and the support of only a few types of nodes. 
FTAM is meant to be a highly robust service that supports a wide 
range of file types and document structures in a highly heterogeneous 
environment. 

FTAM provides an abstract model of different types of file systems 
using the concept of a virtual filestore. The FTAM implementor needs 
to map that virtual filestore and operations on the filestore into the 
particular file system on their implementation. This could be a fairly 
simple filestore with all files on one level and very few file types. Al- 
ternatively, the mapping could be complex as in the case of the Unix 
filesystem which has a complex directory structure including cross ref- 
erences. 

FTAM provides a totally general model of a hierarchical filestore. 
This means that the file is of a hierarchical nature. Currently, FTAM 
does not support other file structures, such as the relational model. 
This should not pose a problem since most implementations of rela- 
tional databases currently map their data into implementation specific 
file types, such as an ISAM file. In the future, ISO may define rela- 
tional or network (cross-referenced) file systems. 

The FTAM model also does not currently support a directory struc- 
ture. All files thus occupy a monolithic filespace. Again, this is not 
much of a constraint since a hierarchical directory structure can be 
mapped into a flat file space. This means that the user interface, the 
user of the FTAM service, needs to be able to reconstruct that hierar- 
chy. 

A file in FTAM consists of nodes and data units. A node has a node 
name and optionally, a data unit (DU). Nodes can have children 
nodes, which in turn may or may not have children or data units at- 
tached to them. A File Access Data Unit consists of a node and all 
children and data units associated with that FADU. The FADU is the 
basic unit of operation in FTAM. Figures 12-5 and 12-6 shows data 
units and file access data units. 

A data unit can be of a several different types, each defined in the 
ASN.1 syntax associated with FTAM. There is no requirement at this 
level for DUs at the same level to be of the same data type. 

To provide a lesser degree of generality, and hence a higher prob- 
ability of various systems supporting FTAM, ISO has defined a variety 
of context sets and documentation types. A constraint set is a general 
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Fig. 12-5 Virtual filestore. 


definition imposed on a filestore. For example, the sequential flat con- 
straint set imposes a root node with no data unit and one further level 
of nodes with an optional data unit associated with them. Nodes do 
not have a node name associated with them. 

A more complicated structure is an ordered flat constraint set. In 
this set, node names can be used to insert or delete data. An ordered 
hierarchical constraint set allows several levels but imposes the re- 
quirement that the node names of children of a common parent be 
unique. 

The next level of definition is a document type. A binary document 
type can use the sequential flat constraint set and requires that data 
units consist of a series of bytes, as opposed to an arbitrary set of bits. 
Another document type is unstructured text. This uses the unstruc- 
tured constraint set (a root node with a data unit and no children) and 
imposes the further structural limitation that data consist of printing 
characters and spaces. 

The basic FTAM operation is to traverse this hierarchical filestore, 
or tree. This is done in preorder traversal sequence. This means you 
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Fig. 12-6 File access data units. 


visit every node to your left as far as you can go. Then, you go as 
short a distance to your right as you can, followed by another traver- 
sal to your left. In this way every node is visited. Each node is as- 
signed a sequence number based on the preorder traversal sequence. 
This mechanism is a way of imposing a linear structure (needed for 
transmission over the network) on a hierarchical system. 

FADUs can be referenced by the unique sequence number or by a 
FADU name. A list of names can also be used in operations such as 
erase. A series of logical traversal operations, such as first, last, next 
and previous, are also available for referencing FADUs. 

Once the FADU is located, several operations are associated with 
that element. Users can erase a data unit or read it. To read a data 
unit, an access context is specified. This tells the FTAM service 
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whether you want the entire FADU, the root DU, all DUs (with or 
without node names), or the information content of the FADU. The 
information content is a series of node names plus a flag indicating 
the presence or absence of a data unit. 

Several other options include the ability to insert a new FADU or to 
extend the data unit associated with the root of the FADU. Note that 
all these operations assume your version of FTAM already knows 
about this particular group of files, usually by specifying a document 
type. A fully general implementation would allow an FTAM instance 
to learn about a foreign filestore and its structure during a session. 
This is the function of data dictionary standard such as the Informa- 
tion Resources Dictionary System (IRDS). 

Associated with a filestore are a series of attributes. Operations on 
these attributes are the management functions of FTAM. One file at- 
tribute is the file name. A file name can have directory and subdirec- 
tory information implied in the name if the other user of FTAM is 
aware of this. 

Important attributes are permitted actions and access control. Per- 
mitted actions refer to the file as a whole. The access control informa- 
tion extends and further limits the permitted actions to individual 
users. Permitted actions include insert, read, replace, or erase a 
FADU or they extend a data unit. Another attribute controls the 
ability to read or change particular attributes or delete the file. A 
third series of actions limit permitted FADU location methods to for- 
ward traversal, forward and reverse traversal, or random access by 
FADU node names or numbers. 

The access control list is based on either a password or an authenti- 
cated user name or unauthenticated application titles. Note that any 
one of these allow the set of permitted applications. If passwords plus 
the application FTAM$SPECIAL are in the access control list, a user 
without the password could masquerade as the application name 
FTAMS$SPECIAL and gain access to the data. 

Another set of attributes is used for accounting purposes. An ac- 
count can be established with that pays for storage charges (and this 
attribute can be read by foreign users assuming they are permitted 
to). Other attributes contain the date, time, and identity of users who 
created, last modified, or last read data in the filestore. 

A file availability attribute is useful for systems that have large op- 
tical disk farms or tape systems. A deferred availability file definition 
is implementation specific and could mean a 2-second wait or a re- 
quirement to send a truck to Iowa to find the data. This allows the 
filestore to function as a sort of data dictionary. 

Attributes can also include a definition of the document type name 
or of a combination of constraint set and abstract syntax. The last two 
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Fig. 12-7 FTAM regimes. 


attributes are implementation specific. A legal qualifications attribute 
is used to inform users of copyright and other legal constraints. A 
private use attribute is totally undefined (and strongly discouraged) 
but provides a hook for local attributes. 
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FTAM operation is based on a series of regimes, which are typically 
associated with lower level sync points. Regimes are nested, and you 
can't exit an outer regime without first exiting the inner ones. To 
begin with, the association regime is used to identify users, set up 
billing accounts, and negotiate overall capabilities. The conclusion of 
this regime would probably result in a message identifying charges 
accrued, although this could also be done in an inner regime. Figure 
12-7 shows FTAM regimes. 

A file selection regime is the next level. This is used to select or 
create files and to read or change attributes. This level is also used to 
apply the first series of concurrency controls or locks on a file. 

Next, a particular file is opened. At this time, the user can adjust 
concurrency controls. Users can also perform operations on FADUs 
that don’t involve data transfer, such as locate or erase operations. 
Finally, the innermost regime is a data transfer regime used to read, 
insert, or extend FADUs and data units. 

An optional capability of FTAM is to use the services of CCR. This 
capability, if available, can be associated to particular regimes on a 
selective basis. The default is to not use CCR since this imposes con- 
siderable extra overhead. This means that in the event of a lower- 
level disconnect (caused by network saturation for example) data can 
be corrupted. It is up to each individual FTAM environment to decide 
what to do in these cases. 


DEC’s FTAM software 


DEC supports FTAM on the VAX/VMS operating system. This VAX 
FTAM software includes an interface to the Digital Command Lan- 
guage. The DCL interface permits the same interface on FTAM files 
as on native files for file copy and deletion and directory information. 
Integration into the DCL interface of foreign file systems was also 
used to make Phase IV distributed data (Distributed File Service) and 
IBM data (Data Transfer Facility) available. 
VAX FTAM supports three of the basic FTAM document types: 


a FTAM document type 1 for unstructured ASCII data with stream 
record formats 

a FTAM document type 2 for sequential text files with variable record 
format and carriage return record attributes 

a FTAM document type 3 for unstructured binary data 
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Job Transfer and Manipulation 


A service not present in DNA but included in most other networks is a 
Remote Job Entry (RJE) service. This allows a batch job to be sub- 
mitted to a remote site and the results either returned or queued to a 
remote printer. Unfortunately, most RJE services are based on a very 
restricted structure of data, usually 80-column records in EBCDIC or 
ASCII format. Transfer or arbitrary files is not permitted. 

The job transfer and manipulation service (JTM) is mean to address 
RJE-like facilities but in a more general environment. Jobs consist of 
work specifications and documents. A job may visit several nodes to 
pick up documents, perform work on several other nodes, and finally 
return the results to a variety of sink nodes. In addition to job trans- 
fer capabilities, several status, reporting, and job control services are 
offered. 

There are two classes of JTM service. The basic class allows opera- 
tions to be performed only at a single node. The full class operation 
allows a deep tree of jobs, including distributed scheduling, the use of 
FTAM to get documents from other systems, and checkpointing and 
recovery capabilities. 

Both classes of JTM require the use of the commitment, concurrency 
and recovery (CCR) facilities. It might be worth noting that unlike 
the concept of a universal, virtual filestore in FTAM, there is no 
universal job control language. You are expected to know the relevant 
commands on each system performing work. 

JTM may involve the cooperation of many different nodes. Each 
node takes on one of several roles. The initiator specifies what work 
should be done by which node. A source node provides documents 
that are incorporated into the work specification. In the basic class of 
operation, the source node and the initiator are usually the same. A 
more complicated scenario might have a variety of source nodes (plus 
access to other documents using FTAM). 

The two other kinds of nodes are executors and sinks. An executor 
performs the work specified by the initiator. The results are then 
shipped to sink nodes. Sink nodes also receive error reports and 
status messages. Figure 12-8 shows the different types of JTM nodes. 

Initiator nodes submit a work specification. The specification in- 
cludes a list of global parameters that apply to all pieces of the job. 
There is then a section that specifies what jobs will be spawned off to 
other executors for completion. Final, there are a series of subjob 
specifications. 

The fundamental unit of work in JTM is the document. Associated 
with a document is a particular work specification. A document can 
be any arbitrary set of information as defined in the accompanying 
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Fig. 12-8 JTM nodes. 


abstract syntax. In the basic class of operation, all documents needed 
must accompany the initial work specification. 

In the full operation, documents can be collected in a variety of 
ways. As before, they may accompany the original job specifications. 
Alternatively, a remote JTM site may be instructed to use FTAM or a 
private protocol to retrieve a particular document. Finally, the job 
may be handed to a JTM relay (a source node) which collects relevant 
documents, attaches them to the work order, and sends the work order 
on. 
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The global parameters for a work order are copied on any clones of 
the work order that are submitted to multiple executors. These 
parameters include the system and user ID from the initiator and a 
unique work order ID for this job. The global parameters also include 
a trace area that tracks all systems that have handled the work order 
at a particular time. 

The global parameters also include instructions on where to send 
different portions of the work order as well as warnings and diagnos- 
tics. There are also specifications of authorization codes and 
passwords included for each of the nodes that do work or deliver 
reports on this particular order. Accounts to charge and security in- 
formation during transfer are also included. 

Subjobs within the work order can be of a variety of different types. 
A document movement subjob is responsible for transferring a docu- 
ment to a particular site. Report movement subjobs are used to trans- 
fer a variety of error and diagnostic reports. 

The last type of subjob included in the basic class is a work 
manipulation subjob. These subjobs request a target node to perform 
some action on a work specification it already posseses. This might be 
a modification of a job, a change in status (such as an abort opera- 
tion), or a request for a particular form of report on job status. 

Within the subjob specification are the target nodes as well as any 
relays needed to collect documents. An urgency field specifies a 
priority for execution. There are also hold instructions which can be 
provided which instruct the target system to hold the job until a 
manual release or a particular date or time has been achieved. 

The actual work to be performed is in a list contained in the subjob. 
Each item on the list is a particular action to take and the name of a 
document to associate with that action. By the time the action is 
taken, the document must be present in the work specification. 

During the course of a JTM operation, a series of reports may be 
issued. Three basic class reports are defined. The usual report sig- 
nals normal or abnormal termination of the job. A second report indi- 
cates that some entity has manipulated the job (i.e., killed it). A final 
basic report is the user message which is used by user applications, 
such as the operating system, to communicate with remote users. 

More advanced reports are available in the full class of operation. 
Reports can be sent upon acceptance of a document, upon modification 
of work specifications, or when no progress has occurred for a period of 
time. Violation attempts by unauthorized users attempting to — 
manipulate the job can also be reported. Finally, accounting informa- 
tion can be sent periodically. 

Job manipulations are performed by selecting a series of options, 
possibly with a wild card specification. These work specifications can 
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then be modified or a status displayed. Two options are available to 
terminate jobs. A kill operation will abort the action and discard work 
specifications. A stop operation will stop that particular action but 
keep the results already obtained for use by future nodes. 

Each subjob also includes instructions for error handling. Upon an 
error, a particular subjob will usually embed diagnostics in place of 
the output document and continue processing. Other options are to 
hold the job for a specified time and retry the action. Finally, an op- 
tion is available to terminate the job and not continue processing fu- 
ture steps. 


Virtual Terminal Service 


The virtual terminal service is particularly challenging because of the 
wide variety of different terminal types available. The X.25 solution 
to this problem is to define a few parameters to use on an X.3 PAD. 
This provides functionality, but the parameter list keeps on growing in 
order to accommodate different types of operations. 

The VT service intends to solve this problem by developing a 
general model of terminal operation and then registering profiles of 
basic types of terminals. These profiles are then available on a 
negotiation basis between VT users and service providers. 

The terminal consists of a variety of objects. These objects may be a 
screen or a printer. Objects are also defined for mice, joysticks, and 
any other form of input/output. 

The VT model defines a conceptual communications area (CCA). 
Both parties to the VT session share this CCA and keep it intact. 
Within the CCA are a variety of objects that represent pieces of the 
virtual terminal. A data structure definition heads up the CCA and 
defines the data structures associated with the different types of ob- 
jects that are operational. Figure 12-9 shows the different parts of a 
CCA. 

The CCA includes a variety of display objects. These display objects 
are one- to three-dimensional arrays that correspond to some portion 
of the terminal, such as the screen. 

Many devices have a larger memory than they are able to display at 
one time. Portions of display objects are thus mapped onto a device 
object which presumably corresponds to some physical device. 

A display object can have up to three dimensions. The basic class 
only applies to characters and character box graphics. A one-dimen- 
sional array is thus a single line of text. A two-dimensional array is a 
screen of text. A three-dimensional array is a multipage terminal 
device. 
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Fig. 12-9 Virtual terminal CCA. 


Associated with each element of a display object is a series of at- 
tributes. The primary attribute is a representation of a valid charac- 
ter. Secondary attributes include color codes for foreground and back- 
ground, emphasis (such as reverse video), and a font to use. 

Related to display objects are control objects. These are abstract 
representations of devices such as lamps, buzzers, or bells. A control 
object has associated with it an information field. This field could be a 
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boolean, as in the case of a lamp being on or off. It could be a scalar 
as in the case of a lamp with a dimmer switch. It can also be a bit or 
character string. 

Objects can be subject to access control. Access control information 
is kept in a special access control store of the CCA. This store has a 
series of tokens which give access rights to any modifiable object in 
the CCA. 

The use of tokens depends on the mode of operation. An 
asynchronous mode allows only one side to modify the CCA. 
Asynchronous mode thus has a single token for the display object. An 
important source of inefficiency in an asynchronous mode is echo con- 
trol. This allows the local VT, for instance, to perform echoing on 
behalf of the foreign host, if desired. This can be turned off, as in the 
case of passwords showing up on the screen 

In synchronous mode, users can perform two-way access to objects. 
Multiple tokens are thus defined which can either remain permanent- 
ly in the possession of one side or can be passed around. 

Because some terminals have local editing capabilities, a variety of 
delivery control mechanisms are defined. This allows a terminal to 
modify some object without delivering the data. If quarantine delivery 
control is in effect, only the net effect of a series of commands is is- 
sued when the local virtual terminal service issues a DELIVER com- 
mand. 

A simpler mode is no delivery control which means that delivery of 
data is at the convenience of the various protocol modules. A form of 
simple delivery control pushes undelivered data through the model. 
This might be used to ensure that a function key redefinition occurs 
simultaneously with the update of the screen display that signals the 
new definition. 

An extended version of the virtual terminal service allows the im- 
position of additional structure in display objects. The extended mode 
defines two types of structures. Blocks are portions of the display ob- 
ject that can overlap; fields are portions of the display object that can- 
not overlap. 

In the basic mode, there is a pointer to the current position within 
the display object array. Extended mode allows further navigation by 
allowing the user to refer to current blocks and fields, move to the 
first or last block or field, or move to the next or previous area. 

Associated with fields is a series of data entry rules used for valida- 
tion. Each field has an entry rules control object (ERCO). This ERCO 
includes a series of rules that specify what to do when correct or incor- 
rect data is retrieved. It also specifies actions to take upon expiration 
of a timer or when the end of a field is reached. A final rule also 
specifies what to do upon release of the VT connection. 
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A variety of profiles has already been registered with the ISO. 
These include a default asynchronous and synchronous mode. Other 
profiles include support for multipage color displays and X.3 pads. An 
important item to be considered is a profile that is compatible with the 
X Windows System discussed at the end of this book. 


Manufacturing Automation Protocol 


The Manufacturing Automation Protocol consists of a family of stand- 
ards that is used to control manufacturing environments. Pioneered 
by General Motors, the MAP protocol set has been very influential in 
determining the final specifications of many current ISO standards. 

At the lower layers, MAP builds on top of existing technologies. 
Normally, the MAP network is built on a token bus network that uses 
a broadband physical media. MAP is used to connect various types of 
nodes to this media, including computers, programmable computers, 
robots, and other intelligent manufacturing equipment. 

MAP allows two types of nodes. Full MAP end nodes are hosts and 
cell controllers that form the backbone of the MAP network. Cell con- 
trollers, in turn, can control a set of limited functionality devices that 
need fast response time using the manufacturing messaging services 
(MMS). | 

End nodes supplement the MMS services with a variety of other 
ISO application-level standards. CASE is used to control the associa- 
tion of two application entities. FTAM is used for file transfer. A 
directory service provides name-to-address resolution to find the loca- 
tion of devices. 

Separate MAP networks can be combined together with either 
bridges and routers. Routers provide a wide area link between two 
MAP networks. In addition, a router may provide a gateway service 
to another environment, such as a DECnet Ethernet. 

The directory services consists of a series of service agents. A client 
services agent (CSA) can operate in a standalone fashion or can query 
a remote directory services agent. DEC’s 2.1 MAP product supports a 
local version of the CSA that queries a local cache of addresses. This 
local cached directory consists a series of user element names and 
various addresses used to locate that user element. ‘The directory 
must contain addresses of all local applications that will accept remote 
requests and all remote applications. 

The manufacturing messaging service consists of a reduced protocol 
suite for use in a real-time environment. The cell controller, a MAP 
end system, provides the bridge to the rest of the MAP network. 
MMS provides a wide variety of services, some of which are somewhat 
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redundant with CASE and FTAM. This is because MMS is optimized 
for devices that do not have time for data to carefully wend its way 
through a protocol stack. An example is when a robot is told to lower 
its arm to put a piece down. At the bottom of the trajectory, it is 
crucial that the robot receive the next command to stop lowering the 
arm, release the piece, and then raise the arm. 

One of the prime functions of MMS is job and queue management 
for a variety of devices. Jobs, as in JTM, consists of a series of com- 
mands to be executed in order. If the remote device supports queuing, 
the specifications are immediately sent. Otherwise, they are queued 
at the initiating device and sent one at a time. 

Nodes in an MMS environment can then provide a journaling 
capability for jobs that are executed. This journal is a series of mes- 
sages that state what event occurred and provide supporting data. 
This journaling capability is required in sensitive industries such as 
pharmaceutical industries to support Federal regulatory activities. 

Remote event management provides an even greater degree of con- 
trol. Remote events can be triggered based on a time limit, the value 
of a particular variable, or the occurrence of a remote command. 
Remote operations can also be tied to the occurrence of a remote 
event. 

MMS messages are also used to access remote variables. Remote 
variables on a device can be defined and typed. Then, the contents 
can be read or changed. Data can accessed by name or by virtual 
location. When data is transferred back, it is represented in an inde- 
pendent external representation. It is also possible to group several 
variables together into one named structure. This allows nodes to 
treat several data items as though they were contiguous even though 
they may be located in different parts of the remote memory. 

Semaphores are used to control access to data or other resources. 
Semaphores can be acquired by the event, for a particular time period, 
or indefinitely. Semaphores are important when a particular device 
may be controlled by several controllers. A guided vehicle, for ex- 
ample, might provide delivery services for several different cells. This 
would prevent a vehicle loaded with paint from being diverted to the 
suede upholstery cell. 

An early application of MAP technology was in General Motors’ 
truck and bus division. Jack Rathsburg presented a description of the 
automation efforts for a series of plants involved in a new series of 
trucks, known as the GMT400 project at the September 1987 meeting 
of the MAP/TOP Users Group. The project involved tying together a 
series of assembly facilities and the supporting fabrication plants. 

Assembly facilities in two locations (Pontiac, Michigan and Fort 
Wayne, Indiana) were both completely wired with broadband cable. 
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24,000 total tap locations were made available and over 3000 taps ac- 
tually installed to allow for modular changes to configurations. The 
broadband cable spans an area of over 5,000,000 square feet of space. 

Each plant had a computer that controlled the plant at a system 
level. Each area of the plant, in turn, had an area manager computer. 
Area managers communicated with cell controllers, which in turn 
worked with the intelligent devices on the network. All together, over 
1500 intelligent devices communicated with 200 nodes. The plant com- 
puters were connected to corporate facilities using a wide area link. 
Corporate facilities included a variety of SNA and DNA nodes 
throughout General Motors. 

Computer equipment in the installation consists of a series of DEC 
computers as area managers. HP cell controllers are then used for 
each individual cell. A variety of different types of robot and program- 
mable logic controllers are used for the different intelligent devices. 

If the system support level for the plant is unavailable, area 
managers are able to function for a period of 8 hours without assis- 
tance. Likewise, cell controllers can function for 2 hours without as- 
sistance from an area manager. 

Automation in the assembly plants includes four main types of 
areas, including the body shop, paint shop, cab and engine trim areas, 
and final assembly areas. Programmable guided vehicles are used to 
deliver materials to their proper locations. An important feature of 
these vehicles is that they are used within areas to allow trim and 
assembly operations to occur in a nonserial fashion. 

The body shop uses vehicles to deliver parts to the appropriate weld- 
ing stations. The parts are welded together using either program- 
mable robots or devices that use “hard automation” (nonintelligent 
devices). 

The paint shop is also automated and consists of a series of different 
paint shops directed by an area manager computer system. Pieces are 
routed into a particular shop and stopped at a particular location, and 
a robot is then used to spray paint the part. The part is then routed 
to an oven which is set to bake the piece to give the paint a hard 
finish. 

The final assembly area includes three different sets of guided 
vehicles that deliver parts. The engine transmission assemblies are 
delivered from an off-line assembly area. The truck cab and box trim 
are delivered by another guided vehicle. Finally, the chassis is 
delivered by a third vehicle. All three vehicles converge at the final 
assembly line. A robot is then used to guide assembly, using a vision 
camera. The vision camera provides feedback to the robot to check for 
proper alignment of openings, hole patterns, and seams. 
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X.400 Messaging Services 


X.400 consists of a series of message-handling protocols developed by 
the CCITT. X.400 has been quickly adopted by most major computer 
vendors as well as most wide area service providers. Versions of 
X.400 are readily available for most computer systems and for most 
countries. Some countries, such as France, have adopted X.400 
wholeheartedly as a nationwide messaging handle system. 


User agents and message transfer agents 


X.400 is built on a concept of user and message transfer agents. This 
split in functionality is very similar to the DTE/DCE split in the X.25 
standards. The user agent is responsible for providing a user inter- 
face to the ultimate user of the message-handling services. The user 
agent then takes a message, puts it into an envelope, and submits it 
the message transfer agent. 

The message transfer agent is the edge of the message-handling sys- 
tem. This message-handling system takes a message, enclosed in an 
envelope, and routes it through the network to a destination MTA. 
This destination MTA in turn gives the message to a user agent, who 
presents the message to the end user. Figure 12-10 show the relation- 
ship of user agents to MTAs. 

Several different sets of protocols help form this environment. The 
P1 protocols are used for communication between different MTA en- 
tities. P3 is the submission and delivery protocol for a user agent to 
communicate with a remote message transport agent. Note that a 
user agent commmunicating with a local MTA is able to use its own 
communication mechanisms. 

The combination of Pl and P38 protocols allows a message to be 
delivered to a final destination. These two protocols thus control the 
handling of the envelope. Another protocol, P2, controls what is inside 
of the envelope. This allows a message to be structured in a way to 
include more than just an arbitrary block of ASCII text. 

The protocol between a UA and an ultimate user is not really part 
of the X.400 protocols. These functions, such as filing messages or 
editing services, are up to the local implementation. A special case is 
when Teletex terminals are connected to the message handling sys- 
tem. A special protocol, P5 governs how these telematic access units 
interact with the network. Figure 12-11 shows the different protocols 
in an X.400 environment. 

Note that the user of the X.400 service may or may not be on the 
same computer as the software user agent. It is possible for a remote 
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Fig. 12-10 X400 user and message transfer agents. 


terminal to be connected to the user agent host using some other 
protocol, such as the X.29 protocols on a packet-switched network. 


Management domains and addresses 


X.400 defines a framework for a worldwide messaging environment. 
Needless to say, the United Nations has not been asked to administer 
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Fig. 12-11 Protocols defined in X.400 model. 


this environment. Instead, the message-handling environment is split 
into a series of management domains. Each country has one (or 
several) administration management domain. This ADMD is typically 
run by the monopoly PTT service provider. 

Attached to an ADMD may be a series of private management 
domains. These would be administered by organizations such as cor- 
porations. A PRMD might be connected to two separated ADMDs, but 
it cannot provide route-through services for the two administration 
domains. This allows X.400 to guarantee control to each individual 
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country. Figure 12-12 illustrates private and administration manage- 
ment domains. 

User agents may be part of either a private or administration 
management domain. Each user of this system is then given a unique 
address, known as an originator/recipient address. An O/R address is 
enough to uniquely identify a particular user. 

Addressing proceeds in a hierarchical fashion. The CCITT has en- 
sured that every ADMD has a unique name. It is up to each ADMD 
to ensure that each PRMD it controls has a unique name. It is then 
up to each PRMD to ensure that every name it assigns is unique 
within the domain. A PRMD might cede naming authority to sub- 
domains, but there must still be a unique name for each user. 

Names consist of a series of naming attributes that together form a 
unique name. Attributes fall in four main categories. Personal name 
attributes include surnames, given names, initials, and a generational 
qualifier. Geographical attributes include streets, cities, regions, or 
countries. Organizational attributes could include the name or the or- 
ganization (or a subunit) but can also include a position or role within 
the organization. 

Special naming attributes are architectural attributes because they 
are architecturally imposed instead of being derived from some exist- 
ing naming system. Architectural addresses can include PRMD or 
ADMD names. They can also include X.121 addresses, which identify 
a network, plus a unique numeric value that identify a particular 
user. Domain-specific attributes might include DNA addresses, VMS 
user names, or other implementation-specific details. 

A collection of attributes helps to form a name. The single attribute 
country name does not uniquely identify a particular user, but the 
collection of country name, some geographical identifiers, and a per- 
sonal name might be a sufficient collection of identifiers to uniquely 
identify a user. A guaranteed collection of attributes that forms a uni- 
que name might be a Telex 121 address with a unique numerical iden- 
tifier for the user of that X.121 address. 

OSI has approved two collections of naming attributes that should 
be supported by each X.400 implementation. This means that any 
message submitted to this management domain, if it has a properly 
formed address, can be delivered or relayed. The two approved forms 
of address are the X.121 form and a “user friendly” collection of ad- 
dresses that consists of a country name, administration and manage- 
ment domain names, and a unique personal name. 

It is up to each management domain to decide how to route mes- 
sages to the ultimate user. If a management domain has its own uni- 
que naming attributes, it may accept supplemental types of names 
instead of just the ones specified by OSI. A management domain 
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might even accept a badly formed name and route it to a user. For 
example, mail might be addressed to the GM PRDM in the US ADMD. 
This is not a complete addresses, but the GM PRDM might specify a 
location to send poorly formed messages. The other option, of course, 
is for the GM PRDM to return the message to the originator as un- 
deliverable. 

The collection of naming attributes is very similar to partial source 
routing in the IP and OSI frameworks. Enough information is given 
so each MTA on the route is able to determine the next MTA to hand- 
le the message. 

The actual route to be used to deliver a message is not specified in 
X.400. This is because to specify a routing algorithm implies some 
issues that are outside of the technical scope of CCITT. Specifying 
routing might lead to a situation in which a West African node is told 
to route messages through a neighbor instead of the more traditional 
use of Paris as a routing hub. Other economic and political issues also 
influence the choice of routes. 


Directories 


Directory services become an important issue in a global messaging 
environment. For the same reason that control is distributed into 
management domains, directories of users also need to be distributed. 
Directory services were part of the original X.400 mandate but proved 
to be difficult enough that they were spun off into a separate X.500 
working group. 

The prime function of a directory service is to verify the existence of 
a name or to match a name to a properly formed X.400 address. With 
the base X.400 specifications, it is possible to specify a probe, which is 
a message with a null envelope content. The user then receives a 
delivery confirmation if the address is properly formed and the service 
elements requested can be supported. One problem with this ap- 
proach is the delay involved in delivering a message all the way to the 
ultimate destination. This is definitely not an interactive option. 

Directories need to form an environment that allows data to be ac- 
cessible globally but updated and managed locally. A PRMD might 
provide a directory of all subdomains it has authorized. The sub- 
domain would then be responsible for updating the list of valid users. 
This implies that each of the decentralized directory providers is 
diligent enough to maintain a valid directory. Some organizations, 
such as military groups, might also make their directories unavailable. 

Assuming that a directory is available, several advanced functions 
are specified as goals of the X.500 specifications. X.500 allows a user 
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to determine if a name is a user or a distribution list. If it is a dis- 
tribution list, the directory can return a list of names that make up 
the list (which in turn could be distribution lists). 

Users are also able to map a partial name into a possibility list. 
The partial name “Joe” at “General Motors” might return a large num- 
ber of names, so it is possible for a particular implementation to limit 
this capability with users. Remember that directory information gets 
returned in the form of a message, which carries a charge just like 
any other message. 


Message transfer service 


The message transfer service (MTS) specifies how user agents and 
message transfer agents interact. To begin with, each message formed 
is assigned a unique ID. This unique ID is used when referring to 
status messages such as nondelivery notices. The message transfer 
services are grouped into five basic service groups. The basic message 
transfer service group includes a set of capabilities common to all MTS 
interaction. 

Included in the basic group of services is the unique message ID, 
submission and delivery time stamps, and nondelivery notifications. 
The basic group also allows some control over the types of information 
that can be delivered. 

The message transfer service is mostly independent of the message 
content. That is a function for the interpersonal messaging protocols 
which interpret the contents of a message. An exception is the ques- 
tion of encoding information. Encoding specifies things like which 
character sets are used to encode a message. 

As part of the basic MTS, a UA can register the types of valid en- 
coded information it is willing to receive. The UA can also indicate 
that a particular message it is sending is encoded in a particular way, 
that conversion is to be performed, or that conversion is prohibited. 

The next major set of services defined for the MTS are submission 
and delivery services. A UA can specify the grade of delivery for a 
message to be normal, urgent, or nonurgent. The precise meaning of 
these service levels is up to each domain to decide. 

Submission and delivery services also allow the UA to specify if a 
delivery notification is desired. Note that this means that a receipt is 
sent when the message is delivered, not when it is read. The UA can 
also prevent the return of nondelivery notifications. Since nondelivery 
notifications are a message, they have a cost associated with them. 
The UA can also specify that in the case of nondelivery the contents of 
the message be returned. 
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A final set of submission and delivery services governs the type of 
delivery. The UA can specify that delivery be deferred and thus not 
occur before a specific time. Deferred delivery cancellation is available 
although there is no guarantee that the cancellation order will catch 
up with the message in time to cancel it. Alternate delivery can be 
allowed, although there is no guarantee that the receiving end knows 
who to deliver the message to. If no alternate recipient is available, 
the message is not delivered. 

UAs are allowed to tell their MTA what conditions lead to the as- 
signment of alternate recipients. This function might of course be 
restricted to certain users. The qualified user would specify what 
combinations of possibly incomplete attributes to use to select a mes- 
sage and then who the alternate recipient is. A UA may also specify 
that messages are to be held by the final MTA and not delivered. This 
is useful for a stand-alone UA, such as a personal workstation, which 
is not always connected to the message-handling system. 

The last groups of service elements in MTS provide a variety of con- 
trols over conversion and status. The conversion elements allow a UA 
to export information to other services agents, such as a Teletex ter- 
minal. 


Interpersonal messaging service 


The IPMS governs the contents of the envelope that is delivered by 
the message transfer service. The contents of this envelope might be a 
message from a user agent or might be a status message, such as a 
return receipt or a nondelivery notification. 

The contents of a message is defined using the same ASN.1 syntax 
used to define other forms of complex documents, such as a file. Figure 
12-13 shows a portion of that ASN.1 definition. The message consists 
of two pieces, a header and a body. 

The header of a message consists of a series of service elements. 
Most of these elements are optional. The basic elements are used to 
identify the basic MTS options that were picked, as well as the type of 
IP message that is being delivered. The IP message could be a status 
message, such as a receipt, or a user-originated message. 

Another basic type of information is the type or types of body infor- 
mation that is included. A message could thus consist of a mix of 
FAX, ASCII text, and other defined formats for the body of a message. 

Another set of service elements are called cooperating IPM UA ser- 
vice elements. This is information used by the two IPMs to convey 
information in addition to that furnished by the message transfer ser- 
vice. 


IM-UAPDU 


:: = SEQUENCE { Heading, Body } 


Heading oa OG! { 
IPMessagelD, 
originator 
authorizingUsers 
primaryRecipients 
copyRecipients 
blindCopyRecipients 
inReplyTo 
obsoletes 
crossReferences 
subject 
expiryDate 
replyBy 
replyToUsers 
importance 


sensitivity 


autoforwarded (14] 


IPMessagelD 
ORName OPTIONAL, 
PrintableString } 
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IMPLICIT ORDescriptor OPTIONAL, 
IMPLICIT SEQUENCE OF ORDescriptor OPTIONAL, 
IMPLICIT SEQUENCE OF Recipient OPTIONAL, 
IMPLICIT SEQUENCE OF Recipient OPTIONAL, 
IMPLICIT SEQUENCE OF Recipient OPTIONAL, 
IMPLICIT IPMessageld OPTIONAL, 
IMPLICIT SEQUENCE OF IPMessagelD OPTIONAL, 
IMPLICIT SEQUENCE OF IPMessagelD OPTIONAL, 
CHOICE {T61String} OPTIONAL, 
IMPLICIT Time OPTIONAL, 
IMPLICIT Time OPTIONAL, 
IMPLICIT SEQUENCE OF ORDescriptor OPTIONAL, 
IMPLICIT INTEGER { 

low(0), 

normal(1), 

high(2) 

} DEFAULT normal, 
IMPLICIT INTEGER { 

personal(1), 

private(2), 

companyConfidential(3) 

} OPTIONAL, 
IMPLICIT BOOLEAN DEFAULT FALSE} 


:: = [APPLICATION 11] IMPLICIT SET { 


:: = [APPLICATION 0] IMPLICIT SEQUENCE { 


StandardAttributeList, 


DomainDefinedAttributeList OPTIONAL } 


ORDescriptor :: = SET { 


ORName OPTIONAL, 


freeformName [0] IMPLICIT T61String OPTIONAL, 
telephoneNumber [1] IMPLICIT PrintableString OPTIONAL } 


Recipient = SET { 


[0] IMPLICIT ORDescriptor, 


reportRequest [1] IMPLICIT BIT STRING { 


receiptNotification(0), 
nonReceiptNotification(1), 
returniPMessage(2)} 
DEFAULT {} 

replyRequest [2] IMPLICIT BOOLEAN DEFAULT FALSE 


Body 
BodyPart 


:: = SEQUENCE OF BodyPart 

:: = CHOICE { 
IMPLICIT IA5Text, 
IMPLICIT TLX, 
IMPLICIT Voice, 
IMPLICIT G3Fax, 
IMPLICIT TIFO, 
IMPLICIT TTX, 
IMPLICIT Videotext, 
NationallyDefined, 
IMPLICIT Encrypted, 
IMPLICIT ForwardedIPMessage, 
IMPLICIT SFD, 
IMPLICIT TIF1 } 


Fig. 12-13 ASN.1 definition of portions of X.400 message format. 
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An example of this supplemental information is a recipient notifica- 
tion. This indicates that not only was a message delivered as specified 
by the MTS, but it was read. The recipient notification includes the 
ID of the message that was read, a time stamp, and an indication of 
what triggered the receipt. This could be the fact that a user interac- 
tively read a message or it could be that the message was printed on a 
printer. 

Another example of cooperating IPM service elements is the autofor- 
warding indication. This lets the IP user (the user agent) distinguish 
a message that was delivered direct from one which was originally 
sent to another user. The UA needs to know this for a variety of 
reasons, including the fact that it will need to break the body of the 
forwarded message up into a message header and a body. The UA can 
also use this information to stop messages from being forwarded more 
than once, possibly in a loop. 

A third set of service elements extend the header provided by the 
MTS to provide more detailed information. A message can have an 
expiration date with a time that signifies when it becomes obsolete. It 
can also have cross references to other message IDs, or sensitivity 
determinations for data that should be treated carefully. The sen- 
sitivity indications might be used by the UA in deciding whether a 
message can be autoforwarded, or printed on a printer with shared 
access. 


DEC’s Messaging Strategy 


DEC has always provided network wide messaging services in the 
DECnet architecture. This has been supplemented with a much more 
comprehensive architecture based on the MAILbus. ‘The MAILbus 
consists of a family of protocols that provides a message transport ser- 
vice, a distributed directory service and various mail management ser- 
vices. The MAILbus Message Router, together with the X.400 
gateway, provides for a fully compliant X.400 P1 message transport 
agent. A somewhat similar system is the SNADS architecture in the 
IBM environment, although SNADS is not X.400 compliant. 

The MAILbus is an architecture which is implemented in a Message 
Router. Users interact with a user interface such as VMSmail or 
ALL-IN-1, which hands messages off to the Message Router (MR) for 
delivery. Figure 12-14 illustrates the MAILbus architecture. 

Some user interfaces have native Message Router support. The 
ALL-IN-1 office automation environment, for example, has built in 
support for the Message Router. Any nodes that have ALL-IN-1 users 
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Fig. 12-14 DEC’s MAILbus architecture. 


also have the MR software running. MR then handles delivery of the 
messages to other MR modules across the network. 

Other user interfaces do not have native MR support. An example 
of this is the older VMS mail system. This software was designed 
with another message-routing component known as mail-11. To inter- 
act with the MR system, a VMS Mail Gateway is provided. This al- 
lows a VMS Mail user interface to hand messages off to the message 
router software and therefore address ALL-IN-1 users. Prior to 
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MAILbus, users of the ALL-IN-1 and VMS Mail systems had to 
manually transfer messages between the two environments. 

Mail gateways are used to provide a mapping between noncompliant 
mail environments and the MAILbus. Each gateway provides three 
major services: 


1. Address conversion between environments 
2. Document conversion between environments 
3. An interface to the network to provide a cross-environment session. 


Gateways can also be constructed using a programmer's kit. The 
programmer’s kit allows a custom environment to participate in the 
MAILbus architecture. An example would be third-party vendors of 
integrated office automation packages who wish to integrate their 
software with the broader DEC environment. 

Other gateways are used by the Message Router to hand mail mes- 
sages off to different types of networks. For example, a Message 
Router/S gateway is able to use the DECnet/SNA Gateway to hand 
mail messages off to the SNADS delivery system which in turn 
delivers the message to a DISOSS user. A PROFS gateway provides 
the same function for the other major IBM office automation environ- 
ment. 

The SNADS gateway must perform two fairly complex tasks. First, 
it needs to remove the Message Router header and replace it with a 
SNADS mail header. This new address along with the original data is 
then handed off to a SNADS delivery agent. 

A second function of the SNADS gateway is to convert the format of 
documents. The SNADS gateway is able to accept WPS/Plus files, 
ASCII files, or DX format documents and convert them into IBM’s 
Document Content Architecture. The SNADS gateway is also able to 
accept MS-DOS files. This feature would be used to send a file be- 
tween a DECnet/DOS node and an IBM token ring PC. 

An X.400 gateway is used to integrate the MAILbus system into an 
even larger X.400 environment. The gateway software translates the 
addresses of the messages into the appropriate X.400 address for out- 
going messages or DECnet-style addresses for incoming messages. 

A directory service is available within the MAILbus architecture. 
This allows users to maintain directories of name equivalencies for use 
in addressing. The directory service is also available to gateway pack- 
ages to perform name translation and validation. The directory ser- 
vices use the facilities of the Distributed Naming Service to maintain 
distributed name directories. 

The Message Router software performs special useful functions in 
the network. It can log messages and perform forwarding on behalf of 
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intermediate lines and can be configured to accept messages and store 
them in a queue until off-peak hours, when they are transmitted. The 
Message Router software runs on every node in the DECnet that has 
either a gateway or a user agent. 

Another gateway that can sit on the Message Router is the VAX 
Mailgate for MCIMail. This allows ALL-IN-1 (or any other use inter- 
face) to access a wide area messaging service operated by MCI. MCI 
in turn has a gateway to the Telex system. MCI Mail also allows 
users to address messages to recipients without electronic addresses. 
Hardcopy is made of the message, and it is sent to a postal address. 
Users can register corporate stationary for use in printing hardcopy 
messages. 

The VAX Mailgate interacts with the message router to accept mes- 
sages. It is configured to use standard modems on an asynchronous 
port. The manager is able to configure the gateway to either dial MCI 
mail with each new message received or to wait a period of time. The 
manager can also specify how long messages can be sent in one direc- 
tion before the direction is reversed and how long to wait after a 
transfer before dialing MCI Mail again. 

Similar to the MCI Mailgate is the Alisa Connection from Alisa Sys- 
tems. This software connects VAX/VMS mail to Western Union’s 
Easylink system. This system has a variety of electronic mail users 
and is in turn connect to the Telex system. It can also link to Western 
Union Mailgram and Telegram services. 

This system has the user address all VMS mail to an account called 
Easylink. The first few lines of the message then contain the address 
of the user. This is similar to the X.400 method of putting an IP 
Message envelope inside of a MTS envelope. Here, of course, there are 
two MTS envelopes. The first MTS is mail-11. The second service is 
Easylink. There may be a third envelope which has Telex or 
Mailgram header information. 

Voice mail access is provided to the ALL-IN-1 environment using 
the DECtalk Mail Access Package. DECTalk is an I/O device that is 
able to “speak” an incoming data stream. DECtalk speaks all words 
in its dictionary or in a user defined dictionary. Ten different voices 
are available. This interface allows users to dial into the DECtalk 
system and have ALL-IN-1 messages read to them. 


Summary 
As can be seen in this chapter, the OSI protocols provide a highly 


functional open networking enviornment. The OSI network, transport, 
and session layers provide a common set of services used by applica- 
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tions in dissimilar environments. The services in OSI allow a variety 
of sophisticated forms of information exchange to take place among 
many different types of systems. 

DEC’s support of OSI in DNA Phase V is a particularly important 
step in the development of an open network. Other OSI-compliant 
vendors can integrate with DEC equipment in a tightly integrated net- 
work. While previous interconnection might have been limited to 
remote log-in using a primitive terminal emulator or a file transfer 
mechanism, OSI networks allow the full range of data access, job con- 
trol, virtual terminal, and message exchange. As OSI continues to 
develop, more sophisticated services such as heterogeneous distributed 
database systems will become available. 

DNA Phase V is the continuation of a long-term DEC committment 
to sophisticated networking. DNA Phase I was one of the earliest 
available commercial networks. It allowed simple file transfer between 
two directly connected PDP systems. In a Phase V network, this has 
been expanded to provide support for an open, distributed processing 
environment with both greater performance and greater functionality. 


For Further Reading 

CCITT, “Data Communication Networks Message Handling Systems 
Recommendations’, vol. VIII, X.400—X.430, VIIIth Plenary Assemb- 
ly, Malaga-Torremolinos, 8-19 October, 1984 (Red Book). 


Rizzardi (ed.), Understanding MAP, Society of Maufacturing En- 
gineers, Dearborn, Michigan, 1988. 
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X Windows 


Overview of X Windows 


Several of the protocols examined earlier, particularly DNA CTERM 
and LAT, were designed to solve the problem of interactive use of 
remote computers on the network. CTERM is a fairly inefficient solu- 
tion to a virtual terminal service, but it has the advantage of being 
able to operate over a wide variety of data links, including wide area 
links. CTERM provides only a basic terminal emulation function with 
very few additional functions that would permit more sophisticated 
actions over the network. 

The LAT protocols are a more efficient solution to virtual terminal 
services because they make direct use of the data link layer and 
bypass services at layers 4 through 6. The LAT protocols also offer 
some value added services such as service directories and load balanc- 
ing based on service ratings. 

Neither LAT nor CTERM address problems that are inherent in a 
workstation environment characterized by bit-map graphics screens. 
LAT and CTERM assume a fairly low volume of data sent over the 
data with a low level of graphics complexity. VT240-style ReGIS 
graphics can be supported, but bit-mapped screens with icons, multi- 
ple windows, and sophisticated graphics are not part of the model. 

The X Windows System provides support for complex windowing en- 
vironments that function across a network. Without X, a VAXstation 
can open a window that serves as a VT'100 emulator. The VAXstation 
can then use the resources of a foreign node through use of the SET 
HOST command in VMS and the CTERM protocols. A true windowing 
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Fig. 13-1 DEC’s X Window implementation. 


environment differs from this by allowing remote applications to 
manipulate multiple windows on a display. Multiple processes on 
multiple remote systems can write information to the screen in a coor- 
dinated manner. 

Figure 13-1 shows the difference between simple VT100 emulation 
and a true windowing environment. Notice in the X Windows example 
the use of special purpose windows, such as icons. An icon is a win- 
dow that represents another window. When the user selects this icon, 
the remote program is able to tell the display to remove the icon and 
replace it with a full-blown window. 

The X Windows System is built around the concept of a server. The 
X server manages a particular bit-mapped display or possibly several 
bit-mapped displays. Remote programs reside on compute servers. 
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These servers are clients of the X server for purposes of displaying 
objects on the screen. Notice that the workstation is in turn a client of 
the compute server for the purposes of running the program. 

Figure 13-2 shows an example of the type of distributed environ- 
ment made possible by combining sophisticated networking protocols 
with an open windowing environment like X. The network allows all 
hosts to be accessible, and the upper layers of the network allow ap- 
plications to communicate. X helps define the nature, or semantics, of 
that communication. X can be thought of as a form of presentation 
protocol. The combination of X and the network allow a true dis- 
tributed processing environment consisting of a variety of servers. 
The servers are all accessible from the user’s workstation. 

Several other window managers also exist, such as MS-Windows for 
the MS-DOS computing environment. The X Windows System was 
developed at the Massachusetts Institute of Technology with support 
by a consortium of companies including DEC, SUN, and IBM. X thus 
differs from proprietary window managers because of its broad-based 
support from a heterogeneous group of vendors. If programs and ser- 
vers built around X windows are developed by a wide variety of ven- 
dors and if these vendors also support a common set of networking 
protocols such as OSI, workstations and compute servers from dif- 
ferent vendors easily integrate to form an integrated, transparent net- 
work. 

A related standard to X windows is PostScript. X provides a very 
sophisticated method of controlling the windows on a workstation, in- 
cluding pull-down menus and other special purpose windows. X is not 
particularly sophisticated, however, in the way it represents the con- 
tent of a window. X allows bit maps to be transmitted across the 
network, but this can lead to huge amounts of data being transmitted. 

PostScript provides a sophisticated language for the description of 
both printed pages and display screens. PostScript is a de facto stand- 
ard for page descriptions on laser printers. Using the same language 
on the screen as on the page offers the ability to have the same output 
in both environments. PostScript will be discussed in the next chap- 
ter. 


X Windows System Basic Concepts 
An X Windows server consists of three components: 
1. A keyboard 


2. A pointer, typically a mouse 
3. One or several bit-map screens for the display of output 
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The X Windows System also assumes a set of programs written to 
use X as the display mechanism. These programs reside on a set of 
computers on a network. Note that a single workstation can be both 
the X server and a compute server for a given user. 

The foundation of an X computing environment is the X library 
(Xlib). These are a set of subroutines in a programming library that 
are used to send messages and receive replies from an X server. 
Programmers must write code that issues calls to this library to start, 
resize, and write to a window or other display operations. Presumably, 
the programmer is also using a set of other libraries, such as database 
management or mathematical manipulation subroutines. The collec- 
tion of all the different libraries plus the programmers code consists of 
an application. An application could be as simple as a clock or as 
sophisticated as a full-featured desktop publishing system or an in- 
tegrated circuit design program. 

Communication between a program that uses the Xlib and an X 
Windows server uses a protocol called X Wire. X Wire is built on top 
of the underlying network, such as DECnet or TCP/IP. Xlib forms the 
application’s interface to the network. In turn, the X server is the 
interface to the display hardware. Even if some other higher-level 
language, such as PostScript, is used to describe graphics operations, 
X Wire is used to transmit the information to the server, and the serv- 
er performs all direct updates to hardware frame buffers. To simplify 
the design of the user interface, the X library is supplemented with a 
series of tools in a toolkit. Tools provide routines that implement a 
series of widgets. These widgets are predefined menus, command but- 
tons, and other often executed tasks. 

A special-purpose tool is a window manager program. Not all X 
servers have to have a window manager. When one is there, it 
provides a series of services to the user such as moving or resizing 
windows, controlling the stacking of windows on a screen, or creating 
a new terminal emulation window. A program may give a hint to the 
window manager about the size window it would like, but it is up to 
the window manager to decide what is allowed. 

The reason a window manager is allowed to decide these functions 
is because of the wide variety of programs that will have to cooperate 
with different displays. Some workstations have tiled displays that 
don’t allow windows to overlap. A program can tell that window 
manager it wants a big size, but it is possible that other programs 
have already used up most of the screen (or tiles). The program must 
then be prepared to either operate in that small environment or tell 
the user that it can’t operate in that small a space. 

All programs must assume the presence of a window manager. It is 
possible that the X server that the client is communicating with 
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doesn’t have a window manager. If there is a window manager there, 
however, there will be some form of a window layout policy. The 
client program requests certain sizes or other attributes. Any one of 
these requests may or may not be granted. Needless to say, this 
means that an application program needs to be written in a fairly 
flexible way. 


Window Components 


A typical window in X actually is composed of three different windows. 
The main region of the window is one window, and this window is the 
one written to by the application. Another window is the title bar and 
this is typically provided by the window manager. Usually, the title 
bar contains a name furnished by the program or the command used 
to activate the program. 

A third window is the scroll bar. Scroll bars are activated by users 
to signal that they wish to see a portion of the output not currently 
displayed. A scroll bar is used in desktop publishing programs to 
move down the page on a document. 

There are many other special-purpose windows which may also be 
used by programs. Icons are a window used to represent a program 
that is active but not displayed on the screen. Menus are also win- 
dows. Since a menu is a window, many systems allow the menu to be 
moved to a different place than the current location. These are known 
as tear-away menus. 

A window has five characteristics that are set by both programs and 
the X server. They are: 


1) Window hierarchy 

2) Window configuration 

3) Depth and visual characteristics 
4) Graphics context 

5) Window attributes 


Window hierarchy 


The basic window for any given display is called the root window, 
which fills the screen. All other windows created on that display are 
children of the root in the window hierarchy. A child window may in 
turn have its own child window. Windows sometimes create children 
with the help of the window manager and sometimes by themselves (a 
sort of immaculate conception if you will). 
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Fig. 13-2 The world according to X. 
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Within a window hierarchy, there are several rules that children 
must obey. A child window cannot display anything outside the boun- 
daries of its parent window. Note that this does allow a child window 
to open a new window that is not within its own boundaries, as long 
as it is within the boundaries of the parent. Secondly, a child window 
cannot receive any input, keyboard, or pointer while the cursor is posi- 
tioned outside of the parent window. 


Window configuration 


The window configuration controls the location of the window. Each 
window has an origin, the upper-left corner, which is relative to the 
parents origin. If the parent window moves, all the children can be 
automatically moved with this relative positioning. Each window also 
has a width and height, measured in pixels. Optionally, a window 
may also have a border. If it does, the window configuration also con- 
tains a border-width parameter which is in addition to the width of 
the actual window. 

The window configuration also contains a stacking order. There 
may be several child windows for a parent. The stacking order deter- 
mines which window is visible if they overlap. Usually, a menu would 
have a stacking order to make it always visible, while data windows 
might have a lower-priority stacking order. 


Depth and visual characteristics 


The depth and visual characteristics of a window are used for bitmap 
graphics. The depth of a window says how many bits of data are used 
to represent each pixel on the screen. A 1-bit display allows a screen 
to be either black or white. A 2-bit display has four possible con- 
figurations and could thus represent four shades of gray or four dif- 
ferent colors. The visual characteristic of a window determines if the 
bit values of a pixel are actually the color (or gray) value of that pixel. 
If they are not the actual values, the bit value is looked up in a color 
map, which translates the value into the actual color. 

A color map allows more colors to be in the universe of possible 
colors than can be simultaneously displayed on the screen. If a 2-bit 
display value was displayed directly on the screen, the manufacturer 
of the display would have to predetermine the four colors. Instead, 
the color map allows the four display colors to be mapped into a range 
of 16 million possible colors that the screen could display using RGB 
parameters or some other display technology. 
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Graphics context 


The window graphics context determines how to interpret graphics re- 
quests. When a program requests that a piece of text be written into 
a window, the graphics context determines what font to use for the 
text. The graphics context also has other default parameters such as 
what color to use for drawing or what width to use for drawing a line. 


Window attributes 


The last characteristics of a window are the window attributes. At- 
tributes include which particular color map to use for translating 
pixels, the border background color and pattern or a window, and 
what type of cursor that window will have. Attributes also determine 
if this window can be displayed, moved, or resized without notifying 
the window manager. 

An important type of attribute for a window has to do with event 
types. Events, such as the cursor being moved, are received by the 
window manager. The window attributes tell the window manager 
which types of events this program wants to receive. Events that this 
window is not interested in are sent up to its parent window. Thus, a 
desktop publishing program may want to trap mouse buttons 1 and 2 
to select menu options. Mouse button number 3, however, may be a 
signal to the root window to create a new terminal emulator. If the 
cursor was positioned totally inside the child window, the third mouse 
button event would be passed up to the parent (root) window. 


Graphics Context and Color Maps 


The graphics context for a window controls all of the output routines, 
except for the border and background of a window which are con- 
sidered to be window attributes. The graphics context sets a variety of 
parameters which are used by the various output requests. Estab- 
lishing the context means that the individual request does not have to 
specify each parameter. A program may define several graphics con- 
texts and rapidly change between them. 

A fundamental part of the graphics context is the effect of a 
graphics request on existing pixels. The pixels could be actually dis- 
played on the screen or could be part of a pixel map that is not being 
currently displayed. A graphics request is not copied directly to the 
destination bit map. First, a copy area is constructed. Then, the copy 
area is moved over to the destination bit map. 
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Three parameters help determine the effect of a copy area on a des- 
tination bit map. A “logical function” specifies how the pixels in the 
two areas combine. A logical function can add the pixels together 
(thus forming a new color on the screen), wipe out old pixels, and 
perform a variety of other boolean operations on the 2 bits of informa- 
tion. 

A pixel is represented by a certain number of bits, known as the 
depth of a bit map, which is related to the number of colors or gray 
scales that can be on the display. A second parameter in addition to 
the logical function is a “plane mask”. The plane mask says which bits 
of a pixel representation will be affected by a copy operation. This 
allows certain planes to be unaffected by operations. 

The last parameter that effects the combining of pixels is the “clip 
mask.” A clip mask is a bit mask of depth 1. Any bits set in the clip 
mask signify that those portions of the destination clip mask are not 
affected by the copy operation. 

The programmer is thus able to filter out planes of bits through a 
plane mask as well as regions of bits through the clip mask. The 
remaining bits are combined with the copy area using the logical func- 
tion that was specified. Figure 13-3 illustrates the effect of a clip 
mask on a copy area. 

Several graphics contexts can be defined. Switching between dif- 
ferent contexts is a fairly efficient process. In addition to the mask 
functions, several other line and fill characteristics help make up the 
graphics context. 

Line characteristics set the default width in pixels for a line. A 
style can be defined for the line, such as solid or one of the predefined 
dash patters. A custom dash list can also be specified. A dash pat- 
tern can have fill patterns defined for both the “on” and the “off” por- 
tions of the dash. 

Cap and join styles are also specified for lines. A cap style defines 
how a stand-alone line is terminated. Options include round and 
square caps and the degree of projection. A join style defines how to 
lines meet. Miter or round joins are examples of these options. 

File options are another type of characteristic. Areas can be filled 
with either a solid color, specified by a pixel value or by a tile. A tile 
is a bit-map pattern which is replicated over the area to be filled. Clip 
masks are used to prevent a portion of an area from being either filled 
or tiled. 

Color in an X Windows environment is based on series of red, green 
and blue (RGB) values. Each of these three basic colors is represented 
by an 8-bit value. This allows roughly 16 million different hues, or 
combinations of red, green and blue. 
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Some standard combinations of RGB values and their English 
equivalents include: 


Gray scales are derived from these RGB values. A formula is ap- 
plied to combine the three values into a single value of gray. Note 
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that this means that different shades will end up having the same 
gray-scale values. 

Several kinds of color schemes exist within an X Windows environ- 
ment. A color map is a mapping between a single pixel value and an 
associated set of RGB values. When the X server encounters a par- 
ticular pixel value, it looks up the corresponding RGB values and 
transmits that information to the hardware. 

Color maps use precious resources. Because of that, a client will 
usually use the default color map defined by the server. The 
RGB_DEFAULT_MAP contains over 1 million colors, which ought to 
satisfy most general-purpose applications. A utility named XParse- 
Color is also available which can parse an English name of a color and 
map that to the closest approximation of RGB values in a given color 
map. 


Graphics Manipulations 


X provides a series of utilities that are used for drawing. An impor- 
tant issue is the degree that the X Windows System provides the 
drawing capabilities in a windowed environment. PostScript is an ac- 
companying standard that can also provide much of that functionality. 
One possible implementation is to map Xlib primitives into the cor- 
responding PostScript commands. The PostScript interpreter passes 
the low-level hardware operations back to the X Server, which per- 
forms the actual operation on the screen. 

The basic graphics operations available in X Windows are drawing, 
placing text, using regions, and using images. Basic drawing opera- 
tions include points, rectangles, and arcs. More sophisticated com- 
mands include polylines and disjoint polylines. A rule set in the 
graphics context determines if a point in a polygon is on the inside or 
outside of the polygon. 

Fonts in X are a series of bit maps. The fonts can either be constant 
or proportional width. Fonts are defined by a series of font properties 
that contain information such as the size of the smallest character or 
a width table to be used for spacing proportional fonts. Font proper- 
ties also determine display characteristics such as the minimum, nor- 
mal, and maximum interword spacing or the offset for superscripts 
and subscripts. 
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Regions and images 


Regions are an arbitrary set of pixels on the screen, identified by a 
region ID. The region is usually defined by a polygon although it can 
be defined by a list of points. A given region in X can be moved, 
shrunk, or increased in size. Regions can be combined as intersections 
or unions. 

Regions are useful because they can have their own graphics context 
which is independent of the window to which they belong. Region 
definitions may well define the boundaries of a window. These pro- 
vide easy ways to change the size or location of a window area. When 
a window manager allows a user to resize a particular window, it is 
applying a region command. 

Images correspond to an area of the screen or to a particular bit 
map. Images are used to define pieces within a window. Image 
operations include the ability to change each pixel in an image by a 
specified color. This is how clicking on a component of a drawing 
leads to that image changing in color to signify that it has been 
selected is accomplished. 

Images can be composed of other images and thus help form build- 
ing blocks within an area. When you add a pixel to the screen, it is 
typically added to a particular image. That image might then be part 
of one or several regions. An example of using images is providing an 
iconic representation of a window to the window manager. 


Cursors 


Cursors are a special kind of output because they are transient and do 
not destroy the underlying information as a general rule. The excep- 
tion to this rule is when the cursor is used in a draw like function. 
Each window has a cursor defined. If the window does not define a 
particular cursor, it inherits its parent’s cursor. 

A cursor has two pieces to it: a mask bit map and a cursor bit map. 
The mask is the area covered by the cursor. The cursor bit map is the 
actual shape of the cursor. Thus a cursor bit map might make an 
arrow that pointed to a particular edge of the mask bit map. The hot 
spot defines where in this mask the cursor actually points. Figure 
13-4 shows the different components of a cursor. 
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Fig. 13-4 Cursor components. 
Events 


Events are defined as “incidents of importance.” A program might 
receive an event that signals a change in pointer position or a key 
pressed on the keyboard or any other form of user input. Events are 
also used to communicate with a window manager or other programs. 

Every input event that occurs is trapped by the X server, which 
then delivers the event to a window that is interested in that event. 
Windows are in a hierarchy, with the root window at the top and a 
series of parents and subwindows underneath it. The default delivery 
for an event is initially the smallest visible window that encloses the 
pointer at that time. 

A particular window indicates what kinds of events it is interested 
in receiving. Events are selected using an event mask. If a window is 
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Example Types of Masks Available in X Windows 
No Events Desired 


Key Press 
Key Released 


Any Mouse Button Pressed 
Particular Mouse Button Pressed 
Mouse Button Released 


Pointer Motion 
Pointer Motion While Button Down 


Enter Window 
Leave Window 


Window Exposed 
Change in Visibility of Window 


Change of Size 
Color Map Changes 


Fig. 13-5 X Windows system event types. 


not interested in an event, it passes the event up to its parent. Even- 
tually, it is presumed that some window will be interested in an event. 
A special type of selection indicates that the event should not be 
passed up but should be discarded. Figure 13-5 shows some typical 
event types that are available for selection. 

All events that are selected by a mask are delivered into the event 
queue for that particular program. It is important to note that a pro- 
gram is free to ignore events and to even ignore the queue. When the 
program exits, the queue will be destroyed. Figure 13-6 shows the 
delivery of events to different windows. 

There are several general types of masks such as key press events. 
Within that general category, there are specific events for key press or 
key release events. 
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Fig. 13-6 X Window event propagation. 


Events in X are asynchronous. They can occur in any order from 
any number of sources and are queued in the order they are received. 
This means that programs need to be coded in a fairly general manner 
and cannot always expect a particular event to occur after another. 

Grabbing events is a way of prohibiting the user from acting in an 
arbitrary way. When the pointer or the keyboard is grabbed, events 
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do not occur in the normal fashion. Grabbing the pointer might allow 
the program to put a wall around a window and keep the cursor 
within that wall. 

Grabbing the keyboard (or particular keys) prohibits those events 
from being propagated indiscriminantly. A particular grab can be pas- 
sive and only take effect when a certain key (i.e., a certain button on 
the mouse or a function key) is pressed. 

Priorities for grabs occur from the top down. This is how a parent 
window prevents a child from trampling all over input that it 
shouldn’t have. A SHIFT/F1 key, for example, may mean nothing to the 
word processing program but might be an indicator to the window 
manager to open a new terminal window. The SHIFT/F1 key would 
then be passively grabbed by the window manager (which owns the 
root window). 

Exposure events are a special notification that a portion of a window 
previously hidden is now exposed. The default in X is for the server 
not to keep track of window contents. When an exposure event is 
received, it is up to the client program to be able to redraw that area. 

Border-crossing events are used to notify a window that the cursor 
has entered or left its area. A virtual border crossing is when the 
pointer has crossed from the subwindow of one parent to the subwin- 
dow of a second parent. Both of the Sues would then receive vir- 
tual border-crossing events. 

A peculiar type of event is the focus event. If a user is typing on the 
keyboard and the mouse is bumped by a pet cat, all further input may 
go to another window. If that’s the case, the input may be lost, espe- 
cially if the cursor now points to the root window. Changing the input 
focus ensures that certain events are always delivered to the window 
that owns the input focus or to one of its subwindows. Normally, a 
window manager has the input focus set to the root window, meaning 
that all events are delivered as normal. 

An event that cannot be masked out is the client message. This 
allows to client programs to interchange messages. An 8- to 32-bit 
message type identification is added to client messages, although the 
X standard makes no attempt to define what these numbers mean. 


Properties and Selections 


Properties are a way of naming pieces of information. A property is 
an abstract mechanism and is kept by the server for use by clients, 
including the window manager and various user programs. A selec- 
tion is a special kind of property, maintained by the root window but 
containing application-specific information. Properties and selections 
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use events to notify clients that are interested in the existence or 
change in either of these. 

A property has a name and several attributes associated with it. 
This includes a type indicator, a data format indicator, and a data 
area. An example of a property is a default iconic representation for a 
window that is available to clients that do not supply their own. 
Other properties might be a set of hints to client programs that specify 
sizes that are in an acceptable range for use in this environment. A 
further property is a program name associated with a client. The win- 
dow manager might use this to display a name in the title bar of the 
window. 

Selections are a property used by clients and passed around. A 
selection can be acquired and then the current value of a selection can 
be used by the acquiring program. For example, when text is high- 
lighted and then “cut” to a clipboard, the contents of the highlighted 
area is passed to the clipboard as the contents of a selection. 

Selections are acquired by passing a call to the X Server to acquire 
that selection and give it a name. Other programs can then send a 
SELECTIONS$REQUEST to the owner. The owner takes the request and 
stores the results as a property. Then, a SELECTION$NOTIFY is sent to 
the client program that requested it. 

One of the important roles of properties is to hold hints for a par- 
ticular environment. Hints are properties maintained by the window 
manager that tell client programs of various policies it has. This 
prevents a client program from attempting an operation that is incom- 
patible with the display. A small display might have a window 
manager that would hint that windows start up as small entities 
rather than cover the whole screen. Hints allow civilized programs to 
communicate in a networked environment and to share a common dis- 
play. 

It is important to note that the X server maintains properties but 
gives no meaning to the information it stores. It provides a 
mechanism for keeping the properties and a set of events used to 
notify other clients of the existence or change in a certain property. 
The main user of properties is the window manager. 

These window manager hints are varied in different manners. 
Hints are used to tell the window manager if a program wishes to 
begin life as an icon or as a true window. They tell the window 
manager how the program expects to receive input, i.e., if it is real 
estate driven and will only take input when the cursor is in a visible 
area of the window or if it grabs the input focus and takes all events 
while active. 
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Customizing the X Window Environment 


Each user is able to set a series of defaults in a file that is automat- 
ically read upon startup. This file can include default information 
that applies to the whole X environment, such as a default border 
width or a default font. Other types of defaults can be specific to a 
particular program. For example, a user might specify certain charac- 
teristics for a calculator and a mail program in the X default startup 
file: 


font: fixed 
.borderwidth: 2 


xcalc.IconStartup: on 
xmail.IconStartup: on 
xmail.notify: on 
xmail.AutoReceipt: on 


This file would set fonts as fixed and windows with a thin border. 
When the X display starts up, the user will see icon representations 
for mail and a calculator, assuming that the command was issued to 
start them up on default—otherwise when they do start, they will be 
icons. 

When the mail program is running, it is told to notify the user 
whenever new mail is received. This would probably occur through a 
mail delivery program notifying the mail program of new mail or by 
the mail program scanning the date modified field of a particular file 
periodically. Using either mechanism, the mail program would then 
change the iconic representation from a mailbox with the flag down to 
the mailbox with a flag up. 


The X Toolkit 


The X library provides a set of primitive routines and makes no at- 
tempt to specify the user interface. While this provides a great deal of 
power in constructing applications, it allows the possibility of trying to 
reinvent the wheel many, many times. The X toolkit contains a series 
of routines that can be used by application programs. 

There are two main types of tools in the toolkit. First, there is a 
default window manager available that is used in most implementa- 
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tions of the X server. The second type of tools are used for building 
and maintaining widgets. 

Widgets are predefined tools that programmers can use in their ap- 
plication. For example, a scroll bar is an example of a special purpose 
window that is used to control scrolling in another window. Rather 
than initialize this special purpose menu, the programmer is able to 
use the standard scroll bar widget contained in the toolkit. 

There are two levels of interactions with widgets. First, there are a 
set of intrinsic routines in the toolkit used for maintaining and 
developing widgets. There are also some predefined widgets main- 
tained in a database. 

The intrinsic routines allow widgets to be easily created, managed, 
and destroyed. Tools are available to define widget initialization, run- 
time configuration, and the uniform of handling of common events. 
Over 90 intrinsic routines are available to manage widgets. 

There are three important characteristics that make widgets espe- 
cially powerful. First, widgets can be placed into classes. Second, 
widgets can bind certain attributes at run time from a database. 
Third, widgets can be composed of other widgets. 

Widgets belong in a class hierarchy. Lower-class widgets inherit 
selected attributes from widgets higher in the class hierarchy. In ad- 
dition to attributes, such as border width, widgets can also inherit 
methods or procedures from higher-class widgets. 

Run-time binding allows widgets to have characteristics determined 
at run time instead of being coded into the widget definition. Input 
semantics, such as which mouse button activates the widget, can be 
added at run time. Visual appearance, such as the default font or the 
color of the widget, can also be defined at run time. 

Run-time configuration uses a special tool called the resource 
manager. The resource manager is a simple database maintained by 
the X server. The toolkit instructs the X server to load a resource 
database from the file that it is stored in. There can be several 
resource databases, possibly one per user. 

Composite widgets allow widgets to made of other widgets. It is 
thus possible for a programmer to use a set of default widgets and 
some intrinsic routines to define a new composite widget. The com- 
posite widget is now treated like a single object by the application 
program. 


Standard widgets 


The X toolkit has several predefined widgets that are provided in most 
X environments. This means that the application programmer can 
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have some assurance of finding these widgets in a heterogeneous en- 
vironment and can thus depend on their availability. The simplest 
widgets are primitives, such as buttons or labels. 

A label is one of the simplest widgets. It is simply a box with either 
a text string or a bit map inside of it. The text can be optionally right 
or left justified or centered. A command widget builds on top of the 
label. Several actions are defined for this widget, including entering 
or leaving the label. The user of the widget is also notified when the 
relevant mouse or keyboard button is set or unset. 

Another attribute of the command widget is that when the user’s 
pointing device enters the area, the border of the command becomes 
automatically thicker. When the SET action is activated, the widget is 
displayed in reverse video. A further subclass of the command widget 
is the toggle widget, which stays in reverse video even when the set 
button is released. 

An example of a predefined composite widget is the form. The form 
widget takes multiple children and arranges them nicely inside of a 
box. Typically, the child widgets are a series of labels that make up a 
menu. The form includes definitions of minimal acceptable distances 
between children of the form. When the form is resized, it can thus 
rearrange the appearance and order of the children. 

Built on top of the form widget is the dialog widget. This combines 
the general construct of a form with several commands and a label. A 
dialog box might then be used by an application program to control a 
series of operations such as scanning in new input. The SCAN dialog 
box would have commands available to set the resolution of the scan- 
ning and the area to be scanned and to start the operation. 


The window manager 


The second important type of predefined tool in the X toolkit is the 
window manager. The window manager is a special application that 
owns the root window and is thus able to redirect input away from 
client windows. The window manager uses its power to enforce 
cooperation between different programs. Thus, rather than allowing a 
single program to take over the entire screen, the program is forced to 
first ask permission. Presumably, the user has requested this resize 
operation so the request is granted. Certain hardware, however, does 
not allow overlapped windows. In this case, the window manager may 
choose not to grant the request. 
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DECwindows and X 


DEC, along with IBM, Sun, Apollo, and other workstation manufac- 
turers, has wholeheartedly embraced the X Windows System as a 
standard for windowing in heterogeneous networks. DEC has pack- 
aged X Windows along with several other important standard com- 
ponents into DECwindows. 

DECwindows runs on all of DEC’s major operating platforms, in- 
cluding Ultrix and VMS environments. The development of the same 
DECwindows environment across VMS and Ultrix environments was 
the largest single software development project in DEC’s history. This 
includes the development of VMS. 

DECwindows includes an implemenation of the X server. Just im- 
plementing X servers, however, leaves many ambiguities in the user 
interface. This is because the MIT standard of X concentrates on 
providing the means for implementing applications. How they are im- 
plemented is a matter of policy and is not dealt with in the MIT stand- 
ard. 

DEC’s primary enhancement to X Windows is in providing a stand- 
ard “look and feel” for applications. This look and feel concept of user 
interfaces is also present in other standards efforts such as Xerox’s 
Open Look or the SAA Common User Access efforts. 

In all three standards efforts the emphasis is on letting the user 
know in advance how applications work. Things like standardizing 
which key is the HELP key is a simple example of standardizing the 
look and feel. Operation of menus and other forms of controlling the 
dialog are more sophisticated examples. 

In addition to standardizing a look and feel, DEC has extended the 
X graphics model by incorporating additional graphics subsystems. 
PostScript is the primary imaging subsystem that has been added, 
and it provides a common representation of graphics on various 
devices including workstations and printers. PostScript also allows ar- 
bitrary transformation of graphics, freeing the user interface from the 
box-like styles found in X, Macintosh, or MS-Windows environments. 

In addition to PostScript, other imaging systems can be added into 
DECwindows. For example, the PHIGS library for three dimensional 
graphics is supported in DECwindows as an alternate imaging subsys- 
tem. More complex image processing systems can also be added as 
needed. 

The third major enhancement that DEC has done to the X Windows 
standard is the incorporation of language independent features.: These 
are called user interface language (UIL) files and are read in at run 
time. The application developer can develop a language independent 
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application, and language specialists can modify the UIL files for dif- 
ferent national languages. 

The collection of routines that a programmer can use are collected 
together in a client library called the X User Interface. The X User 
Interface provides support for all VAX languages that use the stand- 
ard calling interface. This is an important extension beyond the LISP 
and C languages supported in the basic MIT standard. 


User interface standardization 


Standardizing the user interface with a common look and feel requires 
all the applications programmers to adhere to a common standard. 
DEC attempts to address this problem by standardizing the look and 
feel and then providing a set of tools, or widgets, that conform to these 
policies. This standard look and feel is described in the DECwindows 
Style Guide. The DECwindows Toolkit supplements the intrinsic 
widgets that form the basic MIT standard. 

Note that providing a standard user interface for all programs is 
easier said than done—applications programmers typically enjoy the 
freedom to invent customized interfaces for specific problems. DEC 
has made the Style Guide mandatory for internally produced software. 
For externally produced software, DEC hopes that the DECwindows 
toolkit is easy enough to use that programmers will not want to bother 
with customizing interfaces by resorting to lower layers. 

The common user interface of DECwindows specifies how most 
aspects of an application operate. This includes the layout of the main 
window of an application and subareas as well as the operation of 
dialog panels and the function of the keyboard and pointing devices. 

The main window of an application consists of a title bar that iden- 
tifies the window. The title bar has a shrink-to-icon button and the 
title of the application. The title bar also includes two other buttons 
to push the window to the back of a stack and to resize the window. 

Below that is a menu bar that lists the actions available to the user. 
If the application does not have any options for the user, the menu bar 
can be left off. An example of this is a clock that can only be opened 
or closed. Opening and closing a window are window manager func- 
tions and the application thus does not need any menu options. 

Finally, the window has a work area, or main window. The contents 
of this main window are up to the application to decide. 

Several subwindows can also be defined. The most common ex- 
ample of an application subwindow is the scroll bar. Scroll bars allow 
a user to move the visible portion of the window, or work area, over a 
larger virtual work space. By providing a scroll bar widget in the tool 
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kit, DEC makes it easier for applications programmers to use the sug- 
gested scroll bar actions than it would be to invent a new one. 

Scroll bars are actually a fairly complex application in their own 
right. The scroll bar has a slider, which is a white bar that represents 
the amount of the virtual file that is currently displayed. The user 
can drag this slider up and down to scroll through the application. 
Another motion is to click on the arrows that are on the top and bot- 
tom of the scroll bar. This steps the scroll through by a single unit. 
In a word processor, this unit might be a page of text. 

An even more complex scrolling option available in DECwindows is 
the use of an index window. If the application provides this capability, 
when the slider bar is dragged up and down, the application also 
provides a small window that shows the outline of the application. In 
a word processor, this might be an abbreviated form of the table of 
contents. The user can thus visually see where they are in the overall 
document structure. 

Another type of subarea is a paned window. Paned windows are 
formed by dividing a main window either horizontally or vertically. 
An example of the use of this would be to edit code in one subwindow 
and show compiler output in another. Note that this could be two 
separate applications, each with their own menu instead of single ap- 
plication that has multiple subwindows. Those type of design decisions 
are beyond the scope of DECwindows. Instead, those decisions are 
made as part of the architecture for a family of applications, in this 
case program development tools. 

Dialog control is one of the most important aspects of the stand- 
ardized user interface. A dialog is how a user selects actions to take. 
By standardizing this selection process, a great deal of user training 
can be avoided. 

Many types of dialog management techniques are available. A typi- 
cal example is a control panel, which consists of a series of boxes. 
When the user clicks the pointer on that box, an action is taken. 
Usually, the box contains some iconic representation of the task. 

DEC standardizes the types of controls and labels for those controls 
that are available. A simple type of control is the toggle button—a 
little square with a text description next to it. The standard user in- 
terface specifies that when the mouse button is selected, both the label 
and the box next to it should visible darken. If the user selects that 
option, the label should stay darkened and the box color should be 
inverted. 

Several other options are available for signaling that an action has 
been chosen. For example, an icon can be inverted as in the case of 
the label selection. Another option is to change the appearance of the 
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icon to indicated that it has been selected. Finally, a further selection 
area or control panel might appear with more submenu options. 

In addition to providing standard menus and other dialog control 
functions, the user interface standard goes further by recommending 
how applications should use those capabilities. Matters such as the 
assignment of HELP keys and other common functions (i.e., next 
screen, previous screen) are also standardized. Cursor shapes for dif- 
ferent functions are also recommended. 

The combination of these different levels of definition yields a con- 
sistent user interface. One of DEC’s strongest selling points in many 
markets has always been this common user interface. The VT100, 
Gold-Key style of editing sequences, for example, is fairly standard 
across the help facility, mail facility, word processor, editors, and other 
VMS utilities. This has allowed users to easily pick up new program 
skills without resorting to manuals or extensive online help systems. 
The DECwindows environment allows the common user interface 
present in terminal-oriented applications to be extended to a worksta- 
tion-based environment. 


User interface language files 


The user interface language (UIL) files are compiled and then loaded 
in by the resource manager at run-time. UIL files can exist for dif- 
ferent languages and even different character sets. It is even possible 
to have different procedures and widgets supplied for the different lan- 
guages. 

The UIL file for each language lists each of the procedures, widgets, 
and string labels used by an application that are language dependent. 
Usually, the string values are different for each file but the procedures 
and widgets are the same. It is possible, however, to define different 
procedures for each language. 

For example, a “show text on the screen” procedure might be defined 
differently for Semitic, Latin, and Oriental languages. The Latin pro- 
cedure lays text left to right going down to a new line after each line 
is set. The Semitic language procedure would set text from right to 
left, going down a new line. The Oriental language procedure would 
set text down the page, moving over after each column is set. 

One of the primary users of the UIL feature is the window manager. 
Different countries have different representations of money, time, and 
dates. Sorting orders also differ across countries. This information is 
loaded by the resource manager at run time to customize the Window 
manager interface. 
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Summary 


The X Windows System provides a sophisticated set of library routines 
that allow multiple programs to all share a common bitmapped dis- 
play. These programs can all reside on different hardware platforms 
throughout the network. The programs communicate with an X server 
using the X Wire protocols. 

Built on top of the X Windows System is DECwindows. 
DECwindows supplements X by adding several powerful imaging sub- 
systems. One of these imaging systems, PostScript, is discussed in the 
next chapter. Other imaging subsystems can be used for three-dimen- 
sional graphics or other applications. 

DECwindows also builds a policy on top of the general capabilities of 
X. This policy is a Style Guide, which governs how applications 
present their options to users. This standardized look and feel 
capability allows a user to work with a new software package without 
extensive training. 

DECwindows provides a common user interface across different ap- 
plication programs and different hardware platforms. While the un- 
derlying network, such as DECnet/OSI, provides machine to machine 
communication in a transparent environment, DECwindows allows ap- 
plications to communicate in a complex bit-mapped graphics style. 


For Further Reading 


Nye, The X Window System, Programming Reference for Version 11, 
Release 1, 2 vols., O’Reilly & Associates, Newton, MA, 1987. 


Swick and Ackerman, “The X Toolkit: More Bricks for Building User- 
Interfaces or Widgets for Hire,” Conference Proceedings, USENIX 
‘Technical Conference, February 9-12, 1988, p. 221. 
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PostScript 


Overview of PostScript 


The X Windows System defined a powerful environment for controlling 
and manipulating windows in a heterogeneous workstation environ- 
ment. The X library and toolkit provide a high level language that 
will work in many different environments. A wide range of different 
types of information can be manipulated. This generality has some 
potential drawbacks, however. The chief drawback of X is that it al- 
lows for the manipulation of a bit maps but does not provide high level 
tools for defining the interior of that bit map. 

PostScript is a language or, more accurately, an imaging model for 
describing a page, either printed or on a display. It was developed by 
Adobe Systems based on work completed at the Xerox Palo Alto Re- 
search Center (PARC). The language forms the basis for most laser 
printers and has been extended to many high end typesetters such as 
the Linotronic 300, which has a resolution of 2450 dots per inch (dpi). 

PostScript has several features that make it especially powerful as 
an imaging system. First and foremost, it is device independent. 
That means that a page can be prepared on a device with low resolu- 
tion and then printed on a high resolution device and look the same 
(only crisper). The device independence also means portability—any 
Postscript-speaking application (i.e., a word processor) can communi- 
cate with any printer that is PostScript-compatible. 

A second set of features in Postscript is the power of the graphics 
and text languages. The PostScript system is an especially powerful 
typographic model. Fonts are stored as outlines, allowing them to be 
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displayed at any arbitrary point size. When a region of an X screen is 
resized, text must be redisplayed at a different point size. The X model 
stores these each font as a bit map, which means fonts come in fixed 
sizes. Thus, an X server might choose a font size of 12 or 14 for a 
resized window, whereas PostScript could pick a size of 11.31. 

PostScript was originally developed for use on the printed page. 
However, the power of the language has led to a version that works on 
screen displays. PostScript has been adopted by several vendors as an 
imaging model; they include DEC, Sun Microsystems, and NEXT. 

What PostScript has in the power of the imaging system it lacks in 
the ability to control real estate on a device. X and PostScript thus 
are complementary standards. It is possible to draw a box in either 
language. When PostScript and X Windows are combined, there is 
some choice as to whether to execute a function by a call to the X 
library or the PostScript interpreter. Many of the widgets defined in 
the X toolkit could be redefined as PostScript library calls instead of 
native Xlib calls. 

PostScript code usually consists of a set of highly parameterized pro- 
cedures. These procedures are used by the output module of a pro- 
gram to translate some semantic construction (i.e., a box) into the rep- 
resentation of that object. PostScript performs the same functions as 
the presentation layer of the OSI model. Instead of encoding text in 
some arbitrary ASN.1 syntax, code is specified in PostScript. There is 
no reason, of course, that an ASN.1 definition cannot be developed for 
both X Windows and PostScript. 

Once this presentation layer syntax is defined, a software system is 
able to communicate with its peer in a high-level fashion. In this case, 
the peer is a terminal or printer communicating with some software 
program. What makes this an especially powerful model is that the 
peers are able to represent complex graphics images without resorting 
to transmitting large bit maps across the network. 


Language Structure 


PostScript is an interpreted language. This means that programs are 
not compiled and then run. Instead, a stream of instructions are sent 
to the interpreter, which then processes the information and produces 
the appropriate actions. 

Because PostScript is interpreted, it is context sensitive. Any of the 
commands can be redefined. When a user executes the PostScript 
command show to render text onto a page, that normally prints a 
string of characters. It is possible for another user to redefine the 


Postscript 395 


meaning of the show command. The interpreter would then execute 
the new meaning attached to this command. 

In addition to being interpreted, PostScript is a stack-based lan- 
guage, very similar to Forth. The entire function of the interpreter is 
to manipulate and execute items that are on a series of stacks. These 
items, known as objects, could be a simple object or a complex object 
consisting of other simple objects. An integer is a simple object; an 
array of integers is a complex object. 

When an object is received by the PostScript interpreter, it usually 
deposits that object on an operand stack. An interpreter might receive 
two objects, 1 and 2, each being an integer. Then, the interpreter 
would receive another string object “add.” The interpreter would look 
up the string and see that add is a PostScript operator, or command. 
The interpreter would then take the two top items off the operand 
stack, add them together, and place the results back on the stack. 

There are four stacks for each thread of control, or user, of a Post- 
Script interpreter. It is possible that there are several users, each 
with their own set of stacks. In addition to the operand stack there 
are dictionary, graphics state, and execution stacks. The graphics 
state and dictionary are described in subsequent sections. 

The execution stack is used to hold executions that are partially 
suspended. Execution might begin by processing a file object. Within 
that file, there might be a reference to a procedure to be executed. 
The object file would then be placed on the execution stack and the 
procedure would begin. At completion, the file would then be popped 
off the execution stack and processing would continue. 


PostScript data structures 


Objects in PostScript can be either simple or composite. Simple ob- 
jects include integers, characters, and real numbers. A boolean is also 
a simple object which has a value of true or false. Finally, a name is a 
simple object. 

Composite objects are collections of simple objects. While a simple 
object is put directly on the operand stack, a composite object consists 
of a pointer to some portion of real memory. An array consists of one 
object on the operand stack that points to a portion of virtual memory 
that holds the individual members of the array. 

Arrays in PostScript can be heterogeneous. Each of the elements of 
an array can be of a different type, including another array. ‘This is 
how the simple one-dimensional array definition can be expanded to 
support multidimensional arrays. 
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A special type of composite object is the string. A string is com- 
posed of a series of characters and is thus a special case of the array. 
Usually, when PostScript encounters a string, it is converted into a 
name object. The name object is a simple object, usually referred to 
by a string. The dictionary translates the composite string object into 
a particular name. 


The dictionary data structure 


The dictionary consists of a series of key-value pairs. This makes it 
very easy to redefine the meaning of a command. In fact, the basic 
PostScript commands are not really commands. They are names 
which are looked up in the system dictionary which then point to an 
executable object. 

Dictionaries are stacked up in a dictionary stack. Whenever a name 
is encountered, the interpreter begins searching the first dictionary on 
the stack, then the next, and so on until it reaches the bottom of the 
stack. If for some reason a word is encountered that is not in any of 
the dictionaries, this becomes an error. 

The dictionary is really the only way that PostScript directly sup- 
ports remembering the values of variables. If something is not saved 
in a dictionary and it is popped off the stacks, it vanishes. 

Telling the interpreter to store something in the current dictionary 
is done with the def operator. Thus, when a procedure is defined, it is 
usually in this form: 


/name_of_ procedure 


{ 
} def 


The /name_of_procedure signals to the interpreter that a new name 
is about to be defined or an existing one redefined. The curly braces 
do not actually get stored; they place marks on the current stack as 
the data from the procedure is read in. When the def operator is 
reached, the stack is popped down to the mark and the resulting infor- 
mation is stored as a composite object. The dictionary then contains 
the name of the procedure as well as a pointer to a location in virtual 
memory that holds the composite object. 

The PostScript interpreter stores the definition of all operators in a 
system dictionary. Rather than define operators directly, they are ref- 
erenced in a dictionary. The systemdict contains a series of key- 
value pairs consisting of the name of the operator and the procedure 


Postscript 397 


to be executed. When an operator is encountered by the scanner, it is 
popped off the operand stack and the procedure is found and executed. 

A default user dictionary holds current definitions. Users can also 
create new dictionaries for special purposes. Other dictionaries hold 
errors and procedures to execute when the error is encountered. A 
second dictionary, $error holds information on an error that was ac- 
tually encountered. 


Object attributes 


Simple objects, and the pointer part of a complex object, consist of an 
8-byte representation. This representation describes the type of the 
object, its value, and any attributes. Object attributes signify if the 
object is literal or executable. A literal object is treated as data and is 
put onto the operand stack for use by a subsequent operator. 

An example of a literal object is a literal name. This is signified in 
PostScript by a / followed by a string of characters. This is then typi- 
cally followed by some object to be associated with that name (usually 
in a dictionary). The following code is an example: 


/name 2 def 


When the scanner encounters /name, it converts the string into a 
name and puts it on the operand stack. It then puts the integer 2 on 
the operand stack. 

The def operator is an example of an executable name. The lack of 
the / signals the scanner that this is an executable name and the ac- 
tion associated with that name should be performed immediately. In 
this case, the def operator pops the 2 and the literal name and forms 
a key-value association in the current dictionary. 

The second type of attribute for an object is the access value. Access 
attributes only apply to arrays, strings, dictionary, or files. All of 
these have data that could be sharable because the object points to a 
part of virtual memory. It is possible that another name points to the 
same composite object in virtual memory, hence the need for access 
attributes. 

The four possible attribute values are unlimited (read, write, or ex- 
ecute the object), read/execute, execute only, or no access. An access 
value of none is used to prohibit contexts from accessing certain 
values directly. An example is members of the font dictionary. These 
can only be accessed by special font operators and not by most other 
operators. It is possible for one context to have access to a composite 
object and for another context to have a different level of access. 
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PostScript structure 


Initial input to PostScript goes to a scanner instead of directly to the 
interpreter. The scanner is responsible for breaking up an arbitrary 
string of ASCII data into a series of tokens, or objects. Each of the 
objects, such as integers or booleans, is passed by the scanner to the 
interpreter, which then executes the object. 

The combination of the scanner and the interpreter forms a device- 
independent kernel. This kernel is prepared by Adobe (or a manufac- 
turer of PostScript clones) and compiled for the OEM vendors that 
incorporate PostScript in their products. In addition, three device de- 
pendent modules are provided to interface with the windowing en- 
vironment and the operating system. 

A front-end adapter provides the interface to incoming data streams. 
This adapter dispatches incoming data to the various contexts or users 
of the kernel. Since all input in the X Windows environment is in the 
form of events, the front end adapter interacts with the X Windows 
event dispatching service. 

An operating system adapter is used to provide operating system 
dependent functions. These include special provisions for efficient 
matrix manipulation, a key operation in PostScript. Other operating 
system hooks include memory manipulation and exception handling. 

The display or back-end adapter works with displays on the par- 
ticular implementation. In a display environment, this access is 
moderated by the windowing system, which has control over low-level 
graphics operations. The back-end adapter is used to generate a 
series of device primitives such as bit-map masks, filled trapezoids, or 
half tones. 


User and Device Space 


Every PostScript interpreter presents users with user and device 
spaces. The device space is device independent—it has the same coor- 
dinate system on all PostScript implementations. The device space is 
then translated by the interpreter into a physical device space. 

The user space is used to construct a path, which is then rendered 
into device state. Exactly how it gets rendered depends on the type of 
painting operation and various other state variables such as the cur- 
rent transformation matrix (CTM). Figure 14-1 illustrates various 
transformations of the CTM. 

The CTM defines how each point in user space is translated into 
device space. The CTM is a matrix that can be used to translate, 
rotate, or scale any path in user space as it is rendered. CTM trans- 
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Fig. 14-1 Current transformation matrix manipulation. 
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formations can be accomplished using high level operators such as the 
rotate command. 

It also can perform direct operations on the CTM. All of the high- 
level operations on the CTM, such as rotate, have an equivalent 
direct operation on the matrix. 

A scale operation can thus be represented two different ways: 


35 scale 
or 
[300500 ] concat 


The concat operator concatenates the matrix on the stack with the 
current CTM to produce a new CTM. The scale operation allows 
users to perform the equivalent operation using a single high level 
operator. 

A rotate operation could similarly be represented two ways: 


angle rotate 
or 
[ angle cos angle sin dup -1 mul angle cos 0 0 | concat 


The first element is the cosine of the angle. The second is the sine. 
Since the third element is the negative sine of the angle, the value 
already on the stack (the sine) is duplicated and then multiplied by -1. 

Because PostScript is state based, the order in which operations on 
the CTM are performed is important. A rotate operation rotates the 
user space around the point of origin. A translate operation moves the 
point of origin of the coordinate system. A rotate followed by a trans- 
late is not the same as a translate followed by a rotate. 


Creating and Rendering Paths 


Creating and rendering a path is the basic graphics procedure in the 
PostScript imaging model. Paths are constructed in user space. The 
path is then painted onto device space. The painting operation could 
be a simple fill operation with a given color. It could also outline the 
current path (known as a stroke operation) using the current 
linewidth. 

Constructing a path and then rendering it is used for font displays 
as well as graphics. As will be seen in the next section, the font is 
really just a path. An A is stored as an outline, or path, in the font 
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dictionary. When the show operator is executed, the interpreter fills 
the outline of the character with the current color. 

Two clipping paths are defined that limit the impact of rendering a 
path onto device space. All points in user space that fall outside of the 
clipping path are not shown on the device space when the rendering 
operation is executed. 

The clip path is the basic clipping path used. Like a user path, this 
belongs to the current graphics states When graphics states are 
switched, a new user path and clip path are introduced. 

The second kind of path is a view clip path, which is independent of 
the graphics state. In a windowing environment, the view clip might 
correspond to the overall window. Separate graphics states, and thus 
clip paths, would be defined for each of the components of the window. 

A point in user space must fall within both the clip path and the 
view clip path. The combination of clip paths allows objects to be 
defined without regard for their ability to fit into the particular space 
designed. An example of the usefulness of this construct is a proce- 
dure that generates a circle. The user may only wish a half circle on 
user space. However, that is a more complex mathematical formula 
than that for a whole circle. The user could generate the whole circle 
and then clip it to end up with the desired object. 

Paths are constructed as a series of lines or curves. The path starts 
at the current point in user space. At the most general level, curves 
are defined as Bézier curves. A Bézier curve consists of four points in 
space. The curve itself is a function of the four points. Arcs of circles 
are a special case of the Bézier curve and separate operators exist for 
arcs as PostScript path construction operators. 

A path can thus be used as a clip path or for painting. If the path is 
painted, it can be either filled or stroked. Figure 14-2 illustrates the 
three uses of a path. 


Graphics states 


A user path can be rendered in a variety of ways. The current 
graphics state determines a set of defaults for drawing and painting. 
The graphics state is very similar to the X Windows graphics state. In 
a DECwindows environment, the two graphics states are essentially 
combined. 

A graphics state is a data structure that is put on its own stack. 
This is because a graphics state is accessed frequently and should not 
be mixed on the same stack as operands or dictionaries. When the 
user saves a graphics state with the gsave operation, the current 
stack is saved as a special object. 
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Fig. 14-2 Three uses of a path. 


Graphics states can be saved as a special type of object known as a 
gstate. These gstates are very easy to restore and are thus used for 
rapid graphics state switching. A window-based application would 
maintain a variety of different states, corresponding to different ob- 
jects or subwindows on the screen. 

The current transformation matrix is one of the fundamental pieces 
of a graphics state. A current position, clipping path, and font and 
several device specific parameters are also part of the graphics state. 

The graphics state also includes several components used for draw- 
ing lines. A current line width is defined in terms of user space units. 
A cap style is defined for capping lines that are not joined to others. 
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Cap styles can be round or flat. Join styles specify how joined lines 
are put together. 

Current color is also a part of the graphics state. Color can be rep- 
resented in many different ways, depending on the preference of the 
programmer and the type of output device. Grays are represented as 
a percentage number, where 0 equal black and 1 equals white. The 
translation from this 0 to 1 coordinate system into actual gray-scale 
values on the device are a function of the PostScript interpreter. As 
will be seen in the section on images, many devices cannot use gray 
scales and must instead use half-toning techniques. At this point the 
issue does not concern us and we can assume that the device will 
output grays as close as possible to the specified percentage. 

Color is supported in PostScript using three different models. A 
reflectance model represents colors using the three process colors 
(cyan, magenta, and yellow) and black. This is used in commercial 
typesetting systems. Another model is the luminance model consisting 
of hue, saturation, and brightness. Finally, a mix of RGB numbers is 
available to represent colors. The RGB model is the same as is used 
in a native X Windows System implementation. 

It is fairly simple to process PostScript information and produce 
color separations. A procedure is downloaded to the PostScript inter- 
preter, which takes away all except one of the basic colors in a given 
image. This image is then displayed, usually on a typesetter. The 
same information is printed again with all but one of the other colors 
removed. 


Cached user paths 


In an interactive environment, many paths are defined and accessed 
continually. A special type of object called a user path can be cached 
for rapid access. This cache, like all others, takes up space in virtual 
memory. The path cache is thus limited and committing a path to the 
cache may displace a currently cached path. 

A user path is a special kind of procedure which only contains path 
building operators and nothing else. Since the user path is an object 
type, it can be easily represented in encoded form. This allows the use 
repetition counts and other mechanisms for more efficiently repre- 
senting a path. 

When a path is cached, it consists of a combination of the path as 
well as the rendering operator that was used with that path. In addi- 
tion, a cached path contains the current values of the current transfor- 
mation matrix. This is because the same operators may result in very 
different paths if a different CTM is in effect. 
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The fact that the user path cache is state dependent is no different 
than the method used for font caching. In both cases, when the sys- 
tem receives a font or path request, it checks the cache. If the precise 
one referred to is contained in the cache, it uses it. Otherwise, it 
reconstructs the object in device space. 


Fonts 


Fonts are a special case of the path construction and rendering opera- 
tions. A series of special operators is defined to operate on fonts. In 
most PostScript fonts, the font is defined as an outline. This outline 
can then be scaled, rotated, or otherwise transformed. The default 
operation for rendering a font is usually to fill it with black. By 
changing colors or gray scale, this default can be easily changed. Fig- 
ure 14-3 illustrates various operations on text. 

A font is actually a special dictionary. This dictionary contains, 
among other things, a set of procedures used to draw each character 
in a font. Although fonts are usually used for text characters, a font 
can be defined that has small pictures in it or corporate logos or any 
other form that can be represented as a procedure. 

To locate a particular font, the findfont operator is executed. this 
takes a fontname and returns a dictionary on to the operand stack. 
This font can then be scaled to the appropriate size using the 
scalefont operator. One of the key characteristics of PostScript is 
that outline fonts can be very precisely scaled. 

Fonts are defined in a character coordinate space. Scaling a font 
defines how this character coordinate space is mapped into a user 
space. A more general transformation of character to user space is 
available with the makefont operator, which allows the same type of 
matrix operations that were present for CTM manipulation. 

Once a font has been scaled, it is set as the current font. The cur- 
rent font becomes part of the graphics state. Further manipulations 
to the CTM will affect the font as well as all other components of the 
graphics state. Blowing up a graphics image that contains text with a 
scale command would thus have all the fonts evenly scale in size with 
the rest of the components. 

To simplify setting text, a special operator is available called show. 
This operator takes a string and treats each element of the string as a 
character code. Each of the characters is then set next to each of the 
other characters. 

The decision of which characters go on which line is typically a 
policy decision made ahead of time by the program that is using Post- 
Script. This policy decision is then implemented by PostScript. The 
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Fig. 14-3 Different font transformations. 


show operator simplifies implementing this policy by allowing charac- 
ters to be set as a group instead of individually. 

The decision on where to place each of the characters, using the 
show command, is actually a fairly complicated typographical process. 
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Kerning is used to decide how to space characters. Most typographic 
programs space characters unevenly to provide a more pleasing ap- 
pearance to the eye. This means that the space between words is 
greater than the space between letters on a word. This also means 
that within a word, there is unequal spacing to reflect the unequal 
width of characters. 

PostScript defines two types of kerning. Pairwise kerning looks at 
each pair of letters to make spacing decisions. An A and a W would 
thus be spaced closer together than an A anda B. This is because the 
slant on the W and the A allow them to be squeezed together more 
tightly than the straight lines of the A and the B. 


AW 
AB 


Track kerning is used to squeeze or expand whole lines of text. Big 
fonts, for example, should be squeezed together a little. Small fonts, 
on the other hand need a little extra room between characters to pro- 
vide a pleasing appearance. Several variations of the show operator 
allow a considerable amount of control over the types of kerning used. 
It is even possible, with the kshow command, to have a user defined 
procedure executed between each of the characters in a string. 

While the normal operation is to show a character, it is possible to 
use the character as a path for more general operations. The stroke 
operation strokes a current path using the current line width. It is 
possible to use the charpath operator to render a string as a current 
path and then to show the path. 

Another operation is to fill the insides of text. In this case, the 
character string is again defined as a path using the charpath 
operator. Then, the clip operator is pushed onto the operand stack 
making the path into a clip path instead of a drawing path. Next, the 
user would generate a graphic and show it. The only part of the 
graphic (say a pattern) that would show would be that within the 
boundaries of the clipping path. Usually, the path would then be 
stroked to provide a definition of the boundary of the characters. 


Bit map fonts 


Outline fonts are normally most appropriate, but in very small sizes 
on low resolution devices, the outlines may not be very attractive. For 
these small sizes, hand-tuned bit-map fonts are most appropriate. 
PostScript is able to work with both outline and bit-map fonts, if they 
are available. 
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When an interpreter is initialized (or is coded), it obtains a list of 
fonts that are provided by the hardware or the window system. The 
window system is responsible for interfacing with the hardware en- 
vironment and thus provides the list of available bit-map fonts. 

Once a list is available, the PostScript interpreter knows that it can 
efficiently render those fonts by calling the hardware instead of 
reconstructing the character using an outline and painting operator. 
These small bit maps are available only in particular font sizes and in 
a particular orientation. A rotated font, for example, would have to be 
rendered by PostScript. 


Font caches 


Rendering a character from an outline can consume 1000 times more 
resources than using a simple bit map of the character. To avoid 
reexecuting the character outline, a font cache is established in Post- 
Script virtual memory. Each rendition of a character is cached, along 
with the CTM and other graphics state parameters that were in effect. 
The next time the same character is referenced, it is found from the 
cache instead of being reexecuted. It is not unusual to devote over a 
megabyte of memory to font caches. This provides a tremendous ef- 
ficiency boost in complex text setting environments. 


Images 


Most of the PostScript operations use raster graphics, which consist of 
a series of primitives such as lines and curves. This allows an in- 
dividual component of a picture to be changed without changing all of 
the associated pixels with that component. For most constructions, 
this provides a flexible, revisable way of representing graphics opera- 
tions. Since many devices support raster operations that correspond 
to the PostScript raster operations, this is also an efficient way to 
represent graphics primitives. 

Images are an example of a bit-map type of graphics component. In 
an image, each dot is individually defined. PostScript provides a 
resolution-independent way of rendering images such as photographs. 
Photographs are usually scanned in with a separate program and then 
imported into the PostScript environment. 

Images can also be generated mathematically in the PostScript en- 
vironment. An example of a machine-generated image is a fountain. 
A fountain is a space, such as a rectangle, that gradually changes 
colors or gray scales. 
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To render an image, a set of samples are furnished to the PostScript 
image operators. A sample might be scanned in by a scanner. In that 
case, the number of samples would be equivalent to the resolution of 
the scanning device. Each sample of data can have associated with it 
a color or gray-scale value. 

The PostScript image operator is able to take this sample, which is 
now resolution independent, and transform it into device space. Im- 
ages can thus be rotated, scaled, or translated or any of the other 
matrix transformation operations available in PostScript may be per- 
formed. 

One of the operands to the image operator is a data acquisition pro- 
cedure. This could be as simple as reading a string from the standard 
input. Another option is to have the data acquisition procedure ac- 
tually generate the sample points. In either case, the image operator 
repeatedly calls the data acquisition procedure until it reaches the end 
of the data. Each of the samples is then rendered using the current 
transformation matrix for that image. 

A special provision is made in PostScript for images that are al- 
ready customized for use on a particular device. This allows the imag- 
ing system to efficiently move a bit map onto a device and bypass 
some of the overhead of the image operator. 


Halftones 


Most devices supported by PostScript can render an individual pixel or 
dot on the page only as black or white. The image operator, on the 
other hand, supports up to 256 shades of gray for a particular sample 
of the image. Halftoning is the process by which on/off pixels are 
manipulated to simulate shades of gray (or color). 

When an image is rendered, it is rendered at a particular frequency, 
usually expressed as lines per inch. This frequency makes a grid, to 
which the samples in the image are mapped. A grid or screen of 175 
lines per inch is considered to be a very high-quality image, which 
taxes the limits of most modern printing presses. 

The device resolution of even low-quality laser printers is sig- 
nificantly greater than the frequency of an image. This means that 
several pixels make up an individual square in the grid. By turning 
on a certain number of those pixels, the eye perceives different shades 
of gray. 

The order in which the pixels in a grid square are turned on is 
known as a spot function. The default spot function starts by turning 
on pixels closest to the center of the grid square and then moving 
outward to the perimeter of the square. This means that light grays 


Postscript 409 


appear as small dots and dark grays appear as darker or bigger dots. 
The user is able to specify the type of spot function in PostScript, 
although this is fairly rarely done. 

The halftoning process is unrelated to user space, and it operates 
directly on device space. It can be thought of as a special type of 
clipping mask. The reason that halftone screens are applied directly 
to device space is to make sure that two shades of gray that are ap- 
plied at different times to contiguous portions of device space do not 
show a seam. 

In a color environment, several different halftones can be defined, 
one for each of the colors. A halftone definition, consisting of a spot 
function, angle, and frequency, can be stored in a special halftone dic- 
tionary to allow rapid context switching. The angle of a halftone 
refers to the angle that the grid is rotated from device space. Dif- 
ferent angles are used for different colors so that the dots for one color 
do not overlap with the dots from another color. Because PostScript is 
an opaque painting model and because color combinations are com- 
posed of combinations of the basic color dots, angles are necessary for 
true color output. 


Virtual Memory 


Virtual memory management is important in an environment where 
multiple processes all want to the use the services of one PostScript 
interpreter. This is the case in DECwindows, where a single X server 
and PostScript interpreter make their resources available to multiple 
clients across the network. 

Two types of virtual memory (VM) are available in PostScript. 
Shared virtual memory is available to multiple users. Private virtual 
memory is restricted to one user. Users have their own execution con- 
text (i.e., their own set of stacks). It is possible for several execution 
contexts to share a private VM area. 

Memory reclamation can be performed in several ways. A restore 
or grestore operation explicitly restores a previous state of operation 
and thus automatically reclaims memory. In the case of a page- 
oriented system, this will automatically occur at the end of each page. 

In a display environment, there is no end of page, merely a long set 
of operations on a region of the screen. It is thus possible for objects 
to remain in VM that are not referenced anywhere in the stacks. A 
garbage collector is able to reclaim this VM automatically. 

If a region of VM is to be automatically reclaimed, the composite 
element cannot be on the stack and cannot be referenced by another 
composite element which is on the stack. It is important to note that 
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a composite object might be referenced by a saved context, in which 
case the automatic VM reclamation algorithm leaves it in memory. 

When a new context starts, a separate portion of VM is allocated for 
that process. Normally, each context accesses its own private VM as 
well as the shared VM. Shared VM is typically used to hold font 
definitions and system-wide macros (i.e., X-specific macros might be 
stored here). A rule established for memory allocation says that it is 
illegal to have an object in shared VM point to a composite object in 
private VM. In order to place a composite object in shared VM, the 
process must first allocate some shared VM. 

Normally, shared font directories, the system dictionary, and a spe- 
cially defined shared dictionary are kept in shared VM. Private VM 
contains stacks, the user dictionary, private font directories, and com- 
posite elements. 


Execution contexts and VM 


Each execution context consists of a separate thread of control, which 
means that it has separate operand, dictionary execution, and 
graphics states stacks. Each context also has defined a current input 
and current output file specification. Multiple execution contexts can 
share private VM but only with special coordination by the processes 
involved. 

When a fork operator is executed, this signals to PostScript to cre- 
ate a new context of execution which shares the same VM as the 
original process. As with the Unix fork operator, the child inherits the 
same state as the parent. The child can then keep the same state or 
proceed to modify state information to create a different environment. 

To aid in coordination, semaphores have been defined for use in 
PostScript programs. A mutual exclusion semaphore is a lock on a 
resource. A condition semaphore is similar to the asynchronous sys- 
tem trap (AST) discussed in the context of the VMS _ locking 
mechanism. An example of a condition semaphore is to wait until a 
context has suspended execution for a period of time. These 
semaphores, or synchronization primitives as they are known, can be 
immediately acquired, or the process waits until the resource is avail- 
able. 

A special synchronization primitive allows a context to yield to all 
other executing jobs. This context only executes when no other proces- 
ses are operating. An example of this use would be in an implementa- 
tion of a window manager. A user might specify that the root window 
has a background consisting of a panorama of the Golden Gate Bridge 
and San Francisco, complete with moving waves. It makes no sense 
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for the interpreter to be moving waves if a “real” processes has work 
to do. If nothing is happening on the screen, the intrepter is free to 
use all available resources to create moving waves or even a hur- 
ricane. 


Program Interfaces to PostScript 


PostScript can be accessed at several different levels. At the highest 
level, users can send ASCII text to the interpreter (or more accurately, 
the scanner). Programmers are able to use several other mechanisms 
to access the interpreter. 

Binary encoding is the most efficient method of representing Post- 
Script operations. Binary encoding is equivalent to the internal repre- 
sentation used in the PostScript kernel. Sending data in a binary ob- 
ject sequence (BOS) is equivalent to a program being compiled. The 
compiled program takes ASCII text in a high-level language and 
replaces it with machine code. A BOS is the PostScript equivalent of 
machine code. 

Most programmers will not directly generate binary object sequen- 
ces. Instead, programmers will use two higher-level libraries. The 
PostScript client library provides a procedure for each of the basic 
PostScript operators. 

Another level of access is using a PSwrap preprocessor. PSwrap 
allows the programmer to define a PostScript procedure. That proce- 
dure is then called just like any other C language procedure. The call 
to the procedure returns a status value that indicates success or 
failure. PSwrap allows PostScript to be treated as any other library of 
utilities. 

Both PSwrap and the PostScript client library allow for more effi- 
cient execution of code by replacing ASCII commands with their 
equivalent binary object sequence. Again, the BOS presents a precom- 
piled version of PostScript code to the interpreter, greatly speeding up 
execution time. 


Binary encoding 


Normally, the scanner in PostScript reads all incoming text from the 
current file and parses that information. This scanner functions as a 
lexical analyzer, breaking up the input into tokens that the interpreter 
can recognize. The scanner breaks all incoming data into literal 
strings, numbers, other names, or procedure bodies. This information 


412 DEC Networks and Architectures 


is then passed to the interpreter which performs the appropriate stack 
manipulations and dictionary look-ups. 

In addition to recognizing ASCII text, suitable for sending over a 
nontransparent network connection, the scanner can recognized binary 
encodings. Binary encodings are what the scanner normally produces 
when it has finished scanning information. A binary encoding is thus 
a form of precompiled PostScript code. 

The use of binary encoding implies a fully transparent communica- 
tions channel. The network or communications bus on a machine 
should not add end of line or end record information or otherwise 
depend on the absence of some unique character. While this is 
suitable for a transparent transport mechanism like HDLC, a serial 
line to a printer would not be able to use it. This is because several 
characters (i.e., X/ON or X/OFF) have a special meaning to the com- 
munications software and could not be included as data values. 

The binary encoding mechanism offers several different options for 
representing information. It is possible to represent floating point in a 
native format for the target machine or in an IEEE standard for use 
in a heterogeneous environment. The byte order of incoming data can 
also be specified. 

Every binary token received has an equivalent ASCII repre- 
sentation. The binary encoding thus adds no functionality, only con- 
venience for the programs. There are two ways to perform binary en- 
coding. First, any single command can be represented as a binary 
token instead of as an ASCII token. This is used as a simple compres- 
sion mechanism so long ASCII representations of, for example, float- 
ing point numbers, are not sent over an expensive communications 
channel. 

Each of the tokens sent consists of a packet of data which has a 
token type and a data field. Standard token types are registered for 
native data types in PostScript. In addition, several unassigned and 
unspecified (i.e., window manager-specific) token types are available 
for expansion or implementation specific enhancements. 

A special type of binary token is called the binary object sequence. 
This is a single token which describes an executable array of objects. 
The array of objects described by this binary object sequence is in it- 
self composed of a series of binary tokens, which may in turn be com- 
plex binary object sequences. 

Normally, the binary object sequence functions as a predefined 
series of commands that are immediately executed. This would be like 
defining an executable array (a procedure) and then putting the exec 
operator after it instead of the def operator. It is possible to send in a 
binary object sequence and have it saved for later execution by enclos- 
ing it inside of some ASCII procedure definitions as follows: 
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/proc name 
{ 
[BINARY OBJECT SEQUENCE] 
} def 


In this example, the scanner would put the object on the operand 
stack just as it would any other name definition. If the binary object 
sequence had been received by itself, it would have been pushed 
directly on the execution stack instead. 

The binary object sequence is considered as a whole token by the 
scanner. It thus processes the entire token before sending it over to 
the interpreter. All name bindings are immediately performed based 
on the state of the dictionary stack at the time the BOS is retrieved. 
Because the entire token is processed, it needs to be placed into vir- 
tual memory and thus has to have a finite length. 

The BOS itself consists of a BOS header followed by a series of 8- 
byte representations of binary tokens. This is the same basic repre- 
sentation that is used when a stand-alone binary token is sent over 
the link. 

The header of the BOS indicates that it is a special type of token, 
followed by the number of objects in the top level of the array. Follow- 
ing that is one token for each object in the top-level array of the BOS. 
Next are any objects that are part of nested arrays included in the 
BOS. Finally, there is a space that contains room for all strings 
(which form a composite object). 

Each top-level token in the BOS consists of a 1-byte token type in- 
dicator. This is followed by a length and value field, the meaning of 
which depends on the token type. Simple objects (integers, for ex- 
ample) have the actual value and no length stored. Together, the 
whole token fits into an 8-byte space. 

In composite objects, the length and value fields are really pointers 
to subsequent tokens contained in the BOS. The length field contains 
the number of objects in this composite object. The value field con- 
tains a pointer, which is an offset from the beginning of the composite 
object list within this BOS. 

Since a name is a composite object, the top-level token is really a 
pointer to the text data area at the end of the BOS. A special 
provision for names exist which allows the names to be predefined in a 
name index maintained by the scanner. Name indexes allow names to 
be referred to by a small integer instead of a large character string. 

Two name indexes are defined. The system name index is provided 
with the PostScript interpreter and is used internally by the software. 
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The system name index contains all the standard operator names as 
well as the names of characters and fonts. 

A user name index is also available. To define a name to the index, 
the user pushes an index value and then a character string onto the 
stack. This is followed by the defineusername operator. It is up to 
the user to remember what the index values stand for. 

Name indexes provide a first level of translation maintained by the 
scanner. The dictionary structure provides a second level of transla- 
tion. Once a name has been found, the stack contains an ordinary 
name object. During normal operation, this name is not looked up in 
the dictionary until execution time. 

It is possible to request that a name be immediately looked up in 
the dictionary instead of deferring the lookup until the operation is 
executed. This can be done by setting a special type indicator in the 
token representation or using double slashes in front of an ASCII rep- 
resentation of a name. 

The user name index is part of the private VM. It is possible that 
multiple execution contexts share a space in virtual memory. In that 
case, it is up to all the programs that share that VM to coordinate 
their access to the name index. 


Structured output capabilities 


In the printer implementation of PostScript, a single input stream was 
used to download information. Output consisted only of the printed 
page. In a display-oriented environment, it is important to supple- 
ment this with a way for the interpreter to communicate with 
programs that use its services. 

A structured output capability allows information to be written to 
an arbitrary file as provided by the underlying file system. The im- 
plementation of this is flexible enough to allow different syntaxes of 
file names for different systems. The file system would validate access 
as in the case of any other file access operation. These details, 
naming and other file-system specific semantics, are outside the scope 
of the PostScript imaging model. 

Output sent to files can be encoded with the same binary encoding 
mechanism used for sending information to the interpreter. Type in- 
dicators are available for errors as well as for dynamic token-type 
definitions reserved for use by the application. 
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Library interfaces 


It is possible for programmers to generate ASCII data or binary encod- 
ings and communicate directly to the PostScript interpreter. This 
would involve establishing a connection, generating binary encodings, 
and doing many other complex tasks. Most programmers will instead 
use one of two higher-level interfaces. 

A PostScript client library is a series of routines which are compiled 
into the user’s program. The form of this client library depends on the 
languages used. Typically, this would be the C programming lan- 
guage. 

The client library manages all communications with the interpreter. 
This allows the programmer to treat the connection as a stream inter- 
face consisting of simple reads and writes. The second function of the 
client library is to generate binary encodings on behalf of programs. 
The client library does as much translation as possible at compile time 
to speed execution speeds. 

All of the standard PostScript operators are available as library 
calls. Each of these library calls takes as parameters the arguements 
that the interpreter would expect to find on the operand stack. The 
moveto operator, for example, expects to find an x and y coordinate 
on the stack. The equivalent client library call would be: ) 


PSmoveto ( xcoord, ycoord ) 


The client library is also able to work with multiple execution con- 
texts. The PS calls, such as PSmoveto, always work with the cur- 
rently defined context. To address multiple contexts, a series of 
equivalent DPS (display PostScript) calls are avaiable that take an 
additional arguement for the context ID: 


DPSmoveto ( context, xcoord, ycoord ) 


The second, higher, level of access is a macro library called PSWrap. 
This allows PostScript procedures to be treated like any other C lan- 
guage procedure, complete with a return of status messages. PSWrap 
is a preprocessor which generates C code. That code is then compiled 
and linked in with the client library. 

The programmer begins by defining a C language procedure. That 
procedure is preceded by the defineps indicator, which tells the PS- 
Wrap preprocessor that this is the beginning of some code. The 
endps indicator tells the preprocessor that this is the end of the pro- 
cedure definition. 
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An example of PSwrap, taken from the PSwrap reference manual, is 
to define a procedure that generates a gray circle given an X and Y 
coordinate and a radius: 


defineps grayCircle (float x,y,radius) 
newpath 
x y radius 0.0 360.0 arc 
closepath 
0.5 setgray 

endps 


The programmer could then refer to this procedure in the main body 
of the program with the following call: 


status = grayCircle ( X, Y, RADIUS ) ; 


The same procedure could have been executed by manually setting 
up communication with the interpreter and sending ASCII text or a 
BOS. Alternatively, the client library could have been used, but this 
would have entailed a series of different calls. The client library does 
have the advantage over direct communication with the interpreter of 
managing many of the details of establishing contexts and communica- 
tions paths. 

PSWrap also allows programmers to pass complex data structures, 
such as arrays into the interpreter. Procedures can also return, as 
output, complex objects including arrays and character strings. 


Summary 


PostScript is a full-featured language for specifying the representation 
of text and graphics on a display or other output device. The language 
allows a sophisticated user interface to be built on top of a windowing 
system, such as X. 

The combination of the X Windowing System and the Bost Seri pin im- 
aging system allow bit-mapped workstations to function over a 
hetrogeneous network. That network can consist of many different 
vendor’s compute and print servers. There can also be many different 
user workstations. If applications are written using the OSI network- 
ing standards and the X and PostScript user interface standards, they 
become available to all users on the network. 
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2780/3780 


370 architecture 


3090 


3270 
3274 


3480 
3705 


3725 
3Com 


Glossary 


A model of remote batch terminals used in IBM 
bisynchronous environments. Bisync gateways 
are often referred to as 2780/3780 emulators. 


IBM architecture for mainframe computers, in- 
cluding the 3090 processors. 


IBM top of the line mainframe, sometimes called 
Sierra. 


A series of terminals used in IBM environments. 


A cluster controller for IBM equipment, often 
called a terminal concentrator. 


IBM tape cartridges. 


An IBM communications controller. A PU type 4 
in SNA, used to connect token ring networks, 
cluster controllers, non-IBM SNA gateways, and 
other devices to a PU Type 5 host. 


See 3705 


A communications company known for Ethernet 
controllers and PC-based networking equipment. 
Merged with Bridge Communications. 
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4.3BSD 


4010/4014 


4GL 


80286 


9370 
ACK 


ACL 


ACSE 


ad hoc 


ADMD 


Adobe Systems 


AFI 


4.3 Berkeley Software Distribution The current 
version of the Berkeley family of Unix products. 


A series of Tektronix graphics terminals. A de 
facto standard for graphics terminals. 


Fourth-generation language A group of new lan- 
guages often linked with database packages such 
as Ingres or Oracle. Contrast with Fortran and 
other third-generation languages. 


An Intel chip, used in the IBM PC/AT and clones. 
The 80386 is used in new high-end PS/2s and 
Compaq computers. 


Mid-range IBM processor. _ 


Acknowledge A data communications term for 
acknowledgement of information (packets) 
received. 


Access Control List A security feature in the 
VMS operating system that allows security on 
objects to be specified as a list of permitted ac- 
tions for particular lists of users. 


Association Control Service Elements Core set of 
facilities in the OSI application layer which allow 
application entities to form an association. 


Latin phrase meaning for a specific instance. 
Used in computing to refer to not previously 
planned functions. 


Administration Management Domain X.400 mes- 
sage-handling system concept. Countries will 
typically be an ADMD. They might then cede 
some management authority to a private 
management domain (PRMD). 


The company that makes the Postscript Page 
Description Language. 


Authority and Format Identifier Part of an OSI 
address which signals what type of address fol- 
lows the AFI. 


ALL-IN-1 


Alliant 


ANSI 


APPC 


Areas 


ARP 


Arpanet 


AS/400 


ASCII 


ASN 
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DEC’s office automation shell, consisting of a 
menu driver, a mail user interface, a calendar 
manager, and a file manager. 


A manufacturer of mini-supercomputers. These 
computers are vector processors and compete 
with DEC in the high-end, computationally inten- 
sive markets. 


American National Standards Institute A lead- 
ing standards-setting organization in the United 
States. 


Advanced Program to Program Communication 
Sometimes known as LU6.2, refers to peer-to- 
peer communication in an IBM SNA network. 
Many advanced IBM architectures, such as DIA 
and DCA build on top of APPC. 


A DECnet term used in the routing layer. Level 
1 routers are used to route within a DECnet 
area. Level 2 routers route between areas. Up 
to 1023 nodes may be in an area, up to 63 areas 
in a DECnet. 


Address resolution protocol A TCP/IP protocol to 
translate an IP address into a physical address 
(i.e., an Ethernet or other subnetwork address). 


A Department of Defense sponsored network of 
military and research organizations. Being 
replaced by the Defense Data Network. 


Application System/400 IBM mid range com- 
puter replacing the System/38 and System/36 
product lines. 


American Standard Code for Information Inter- 
change A standard character set which assigns 
an octal sequence to each letter, number, and 
selected control characters. The other major en- 
coding standard is EBCDIC. 


Abstract syntax notation The language used in 
the OSI presentation layer to define complex ob- 
jects. 
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Async 


AST 


AT 


AT&T 


ATM 
AUTHORIZE 


autobaud 


backbone 


backup 


Asynchronous A data transmission method that 
sends one character at a time. Contrasted with 
synchronous methods which sends a packet of 
data and then resynchronize their clocks. 
Asynchronous also refers to commands, such as 
in a windowing environment, that may be sent 
without waiting for a response from the previous 
command. 


Asyncronous system trap A concept used in the 
VMS lock manager. An AST is a request to be 
notified when a certain even occurs. In the case 
of the lock manager, an AST can be set so that a 
process holding a lock on a resource is notified if 
another process tries to take an imcompatible 
lock on the same resource. 


Advanced technology Shorthand for the IBM 
PC/AT or any other Intel 80286-based processor 
that runs the DOS operating system. 


American Telephone and Telegraph Provider of 
long-distance service and computing company 
known for the Unix operating system. 


Automated teller machine Used in banking. 


A VMS utility used to add new users and define 
relevant parameters such as privileges, default 
log-in directories, etc. 


The ability of a modem on the receiving end of a 
call to automatically detect the speed of trans- 
mission used by the calling modem. 


A networking term used to refer to a piece of 
cable used to connect different floors or depart- 
ments together. Contrasted with a departmental 
network or work area network. 


Making a copy of stored information to use in 
case the original repository (usually a disk drive) 
becomes corrupted. To be contrasted with the al- 
ternate meaning of the word, "to overflow," which 
is usually used in the context of plumbing and 
sewage. 


balun 


baseband 


baud 


BBN 


BI bus 


BIND 


BIOS 


Bisynec 


block 


boot nodes 


BOS 


bps 
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balanced /unbalanced An adapter between two 
different pieces of physical media that adjusts for 
the difference in impedence. 


Coax cable implementation of Ethernet. Also 
known as ThickWire. 


A term used with older (slow) modems to refer to 
each modulation of an analog signal. A 300 baud 
signal modulates 300 times per second. A more 
accurate term for faster modems is bits per 
second, as several bits can now be carried on one 
modulation of the signal. 


Bolt, Beranek, and Newman A company that 
specializes in communications. Responsible for 
the Defense Data Network. 


Backplane interconnect A peripheral bus used on 
DEC’s 8000 series VAXs. The BI bus operates at 
a speed of 13.3 Mbps. 


An SNA term used to establish a session between 
two logical units. 


Basic input/output system The MS-DOS library 
of calls for access to data. Shields the application 
from the different types of physical disks. 


A synchronous protocol used in older IBM 
teleprocessing environments. See also BSC. 


A unit of I/O on VMS computers. 512 bytes. 


Used in Local Area Vax Clusters to refer to the 
node that stores the operating system for other 
nodes in the cluster. 


Binary object sequence The lowest level of access 
to a Postscript Interpreter. Higher levels are 
Postscript programming library calls and ASCII 
interfaces. 


Bits per second Transmission speed on modems, 
phone lines, and other data communications 
devices. 
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bridge 


Britton Lee 
broadband 


broadcast 


BSC 
BSD 
bursty traffic 


bus 


CAD/CAM 


CASE 


A device used to connect two separate Ethernet 
networks into one extended Ethernet. Bridges 
only forward packets between networks that are 
destined for the other network. 


Manufacturer of database machines. 


An analog media similar to cable TV. Large 
bandwidth and very long distances make this 
media appropriate for campus settings. Used 
with various data link protocols including Ether- 
net and token buses. 


A message that is sent to multiple nodes simul- 
taneously. Ethernet is an example of a broadcast 
media because all nodes can receive the same 
message. A message with a broadcast address is 
processed by every node on the Ethernet. 


Bisynchronous See bisync. 
Berkeley Standard Distribution See 4.3BSD. 


Data communications term referring to an un- 
even pattern of data transmission. 


The part of a computer that connects devices so 
that they may communicate. An XMI bus, for ex- 
ample, connects memory cards, CPU cards, and 
peripheral buses (the BI Bus). ‘The BI bus al- 
lows multiple peripheral controllers to be con- 
nected. 


Computer aided design/computer aided manufac- 
ture Software/hardware combinations for the 
automation of engineering environments. 


Computer Aided Software Engineering or Com- 
mon application service element A term used to 
refer to a set of tools that help automate and con- 
trol programming environments. Examples of 
CASE tools would be the Module Management 
System or Code Management System from DEC. 
Also a term used in the OSI application layer 
services to refer to a service used by all types of 
application. 


CATV 


CCA 


CCITT 


CCR 


CCS 


CD-ROM 


CDD 


channel 


CheaperNet 
CHIPCOM 
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Community Antenna TV The type of cable used 
in broadband networks. 


Conceptual communications area One common 
view of the state of a virtual terminal used in the 
OSI VT service. 


Consultative Committee for International 
Telephone and Telegraph (Comité Consultatif In- 
ternational Télégraphique et Téléphonique) An 
international standards-making body consisting 
of national telecommunications authorities. 
Recommendations are known by their numbers, 
i.e., X.25 for packet switched networks, X.400 for 
message-handling systems. 


Commitment, concurrency, and recovery Part of 
the OSI CASE services that allows the coordina- 
tion of multiple users access to data on multiple 
nodes. 


Common communications support A portion of 
IBM’s System Application Architecture (SAA). 


Compact Disk - read only memory Optical disks 
that are mastered and then can only be read. 
Used for read only databases. 


Common Data Dictionary DEC’s software that 
functions as a common repository for data defini- 
tions, forms, database schemas, and other parts 
of an information system. Part of the VAX Infor- 
mation Architecture. 


An IBM term referring to a direct high-speed 
connection into the 370 architecture machine. A 
"channel attach" device operates at speeds of up 
to 3 Mbps, as opposed to more traditional devices 
that attach to a communications controller at 56 
kbps. 


Another term for ThinWire Ethernet cables. 


A manufacturer of broadband Ethernet equip- 
ment. 
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CI bus 


CICS 


circuit 


CIT 


class driver 


clearinghouse 


CLNS 


Clusters 


Computer-room interconnect Refers to the 70- 
mbps bus and controllers used in the VAX 
Cluster arrangement. To be contrasted with 
Local Area VAX Clusters that use a 10-mbps 
Ethernet as the transport mechanism. 


Customer information control system An IBM 
data communications interface used typically 
with the MVS operating system. 


A term used in networking that refers to a logical 
stream of data between two users of the network. 
A single physical link may have several virtual 
circuits running on it. 


Computer Integrated Telephony DEC  architec- 
ture and products for integrating PBXs into a 
computer network. 


A term used in VMS. A device driver is used to 
present data to a particular piece of hardware, 
such as a terminal. In VMS, there are two levels 
of device drivers. The class driver is generic, for 
example, a terminal class driver. Underneath 
the class driver is a physical driver that accepts 
commands for a specific type of terminal such as 
a directly connected terminal or a remote ter- 
minal session using the LAT protocols. The class 
driver shields the user of the device from know- 
ing about the particular physical connection 
used. 


A collection of names, such as used in DNS. A 
user would query the clearinghouse (also known 
as a nameserver) to find the location of a par- 
ticular resource at that time. 


Connectionless network service One of two op- 
tions for the OSI network layer. See also CONS. 


A DEC architecture for VMS nodes only that al- 
lows several systems to have a common 
security/management domain and transparent 
access to the same disk drives. 


CMIP 


CMS 


coax 


Cobol 


CODASYL 


concurrency 


conferencing 


config.sys 


connection 
manager 
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Common Management Information Protocol OSI 
network management protocols used in DECnet 
Phase V. 


Code Management System or Conversational 
Monitor System Code Management System is a 
DEC software product used in the VMS environ- 
ment as a library for program development. Con- 
versational Monitor System is the user interface 
on IBM’s VM/CMS operating system. 


coaxial A type of cable, used for IBM 3270 ter- 
minals, as well as for baseband and ThinWire 
Ethernets. 


Common business-oriented language One of the 
first standardized computing languages. See 
CODASYL. 


Conference on Data Systems Languages The 
folks that brought you Cobol as well as the 
CODASYL standard for databases using the net- 
work model of data management. 


When multiple users attempt to access the same 
resource. A lock manager addresses the problem 
of maintaining the integrity of resources in a con- 
current environment. 


A term used for communication software that al- 
lows participants to "post" notes. Contrasts with 
electronic mail in that participants do not have to 
be explicitly addressed. Also known as a bulletin 
board. 


An MS-DOS file read in at boot time which con- 
tains the names of additional device drivers, such 
as a driver for extended memory or a peripheral 
such as a scanner. 


A cluster term used to refer to the software com- 
ponent in a VAX Cluster or LAVC that maintains 
the integrity of the cluster by managing state 
transitions. 
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CONS 


Convex 


CPU 


CRC 


CSA 


CSMA/CD 


CT 


CTERM 


CTM 


CUA 


Cullinet 


Connection oriented network service One of two 
options for the OSI network layer. See also 
CLNS. 


A manufacturer of super mini-computers. See 
Alliant. 


Central processing unit You know—the computer 
part of the computer. 


Cyclic redundancy check A type of error-checking 
mechanism for data communications. A code is 
generated based on the values of the data trans- 
mitted and the resulting number is tacked onto 
the end of the data. The receiving end recalcu- 
lates the CRC and compares it to the CRC 
received. 


Client services agent Part of the Manufacturing 
Automation Protocol (MAP) Directory Service. 


Carrier Sense - Multiple Access /Collision Detect A 
control method for a network. Ethernet is an ex- 
ample of a CSMA/CD type of data link protocol. 


Channel transport An advanced model of DEC’s 
DECnet/SNA Gateway. 


Communications Terminal Protocol Part of the 
virtual terminal service in layer 6 of the Digital 
Network Architecture. An alternative to the 
CTERM services is the Local Area Transport Ar- 
chitecture (LAT). 


Current transformation matrix A term used in 
the Postscript Imaging System to denote the 
transformation between user space and device 
space. 


Common user access The common user interface 
component of IBM’s System Application Architec- 
ture. Similar concepts exist with Xerox’s Open 
Look standard and within the DECwindows en- 
vironment. 


Software company that markets the IDMS 
database package. 


Culprit 


daemon 


DAP 


DARPA 


Data Distributor 


datagram 


DATAPAC 
DB2 


DBMS 


DCA 
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A Cullinet software package used in the IBM en- 
vironment that is used to extract data from other 
DBMS systems such as IMS. 


A Unix term referring to a process that is not 
connected with a user but performs services, such 
as a mail daemon. The equivalent VMS term is 
a detached process. 


Data Access Protocol A protocol used in the Digi- 
tal Network Architecture in layer 6. Provides a 
rich set of functions used for exchanging data be- 
tween two nodes of the network. See FAL. 


Defense Advanced Research Projects Agency A 
Department of Defense agency that has helped 
fund many computer projects including Arpanet, 
the Berkeley version of Unix and TCP/IP. 


A DEC software product for extracting portions 
of DSRI-compatible databases and replicating 
this data on another node of the network as an 
Rdb database. 


An unacknowledged packet of data in a network 
as opposed to packets that require acknow- 
ledgment of receipt (also known as reliable com- 
munications). 


Canadian public packet switched network. 


An IBM database package based on the relation- 
al model and the SQL query language. 


Database Management System Software that al- 
lows the centralized storage of data with multiple 
concurrent users, access control, and the use of a 
high-level data manipulation language such as 


SQL. 


Document Content Architecture or Defense Com- 
munications Agency. Document Content Ar- 
chitecture is an IBM architecture similar in func- 
tion to DEC’s Compound Document Architecture 
(CDA). The Defense Communication Agency is 
responsible for the Defense Data Network. 
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DCE 


DCL 


DDCMP 


DDIF 


DDN 


DDXF 


deadlock 


DEBET 


DEC 
DECconnect 


Data circuit-terminating equipment A term in 
X.25 networks that refers to the interface to the 
communications network. See also DTE. 


Digital command language The user interface in 
the VMS operating system. Similar to the C 
shell in the Unix operating system. 


Digital Data Communications Message Protocol 

A data link protocol used in the Digital Network 
Architecture. Used for point-to-point links be- 
tween nodes, either synchronous’ or 
asynchronous. An alternative data link protocol 
is Ethernet. 


Digital Document Interchange Format The part 
of DEC’s Compound Document Architecture 
(CDA) that specifies how revisable form docu- 
ments are to be stored. 


Defense Data Network A network for the Depart- 
ment of Defense and their contractors based on 
the TCP/IP and X.25 networking protocols. 


DISOSS Document Exchange Facility A DEC 
software product that allows transfer of data be- 
tween DEC and IBM word processing environ- 
ments. See also EDE. 


A term used in a concurrent environment. If one 
user holds a lock on a resource and is waiting for 
another resource to free up and a second user 
has the reverse situation, this is known as a 
deadlock. The deadlock must be broken by ar- 
bitrarily picking one of the users and releasing 
its current lock. The deadlock is also known as a 
deadly embrace. 


Model number for the DEC LAN Bridge 100 used 
for creating extended Ethernets. 


Digital Equipment Corporation 


A DEC cabling architecture used for facilities 
wiring. 


DECmate 


DECnet 


DECnet/DOS 


DECnet Router 


DECOM 


DECrouter 200 


DECSA 


DECserver 
DECtalk 


DECUS 


DECwindows 


DED 


DEFTR 
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A piece of DEC hardware roughly equivalent to a 
PC, but it only runs the WPS word processing 
system and a few miscellaneous utilities. 


An implementation of the Digital Network Ar- 
chitecture by DEC, as opposed to implementa- 
tions of DNA by other vendors. 


The version of DECnet for the PC or MS-DOS 
operating systems. 


A device that routes data between two portions of 
a DECnet. Could be a general-purpose computer 
such as a MicroVAX or a dedicated piece of 
hardware such as the DECSA. 


A broadband Ethernet modem made by DEC. A 
DECOM.-AA is a dual-cable modem; the DECOM- 
BA is a single-cable version. 


A dedicated router with 8 asynchronous DDCMP 
ports and one Ethernet connection. 


DEC Synchronous Adapter A general-purpose 
DECnet Router. The same piece of hardware 
also forms the basis for X.25 and SNA gateways. 


DEC terminal servers. 


A piece of DEC hardware that.can “speak” ASCII 
files. 


Digital Equipment Corporation User Society 
DEC user group. 


A DEC windowing system based on_ the 
Postscript Imaging System and the X Windows 
System standards. 


Dynamically Established Datalink A  DECnet 
Phase V feature that allows a data link to be es- 
tablished on demand, such as a dial-up leased 
line or an X.25 switched virtual circuit. 


DEC Frequency Translator DEC’s frequency 
translator for single-channel broadband systems. 
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DELNI 


DELUA 


DEMPR 


DEMSA 


DEQNA 


DEREP 
DES 


DESTA 


DFM 


DFS 


DHCF 


DHV11 


DEC Local Network Interconnect “Ethernet in a 
Can.” A multiport transceiver made by DEC. 


DEC Local Unibus Adapter An Ethernet control- 
ler made by DEC for UNIBUS processors. 


DEC Multiport Repeater A piece of DEC net- 
working hardware that can connect up to eight 
ThinWire Ethernet segments and optionally con- 
nect them to a backbone cable or DELNI. 


DEC MicroServer A new generation of routers 
and gateways based on the MicroVAX II architec- 
ture as opposed to the PDP-based architecture of 
the DECSA. 


DEC Q-Bus Network Adapter A DEC Ethernet 
controller for Q-bus systems. 


DEC Repeater DEC Ethernet repeaters. 


Data Encryption Standard One type of encryp- 
tion scheme. 


DEC Station Adapter A type of DEC ThinWire 
transceiver. 


DEC Frequency Multiplexor A series of DEC 
products including X.25 asynchronous PADs and 
multiplexors. 


Distributed File Service (or System) A DEC 
product similar to the Network File System 
(NFS). Both allow remote files to appear as 
though they were locally mounted on a worksta- 
tion, allowing diskless nodes. DFS uses the DNS 
nameserver. 


Digital Host Command Facility A DEC software 
product that, in conjunction with IBM’s Host 
Command Facility allows an IBM terminal user 
to log onto a DEC network. 


A synchronous communications board for Q-bus 
(MicroVAX) systems. Less powerful than the 
DSV11. 


DIA 


DISOSS 


DLAL 
DMA 


DML 


DMB32 
DMF32 
DNA 


DNS 


DoD 


DOS 


DOS/VSE 


dpi 
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Document Interchange Architecture An IBM ar- 
chitecture for the interchange of messages. 
Usually used in conjunction with the Document 
Content Architecture (DCA). Implemented in a 
product called DISOSS. 


Distributed Office Support System An IBM 
product that serves as a distributed library of 
documents. See DIA/DCA. 


Dual letter acronym listing See MLAL. 


Direct memory access Allows a device on a com- 
puter to access main memory without a CPU in- 
terrupt. 


Data manipulation language A language, such 
as SQL, used for retrieving and manipulating 
data in a database system. 


DEC BI bus-based communications controller. 
DEC UNIBUS-based communications controller. 


Digital Network Architecture Architecture for 
DECnet. 


Digital Name Service or Domain nameserver <A 
part of DECnet Phase V. Provides name transla- 
tion, such as node name to DECnet address 
translation. Also used for the location of DFS 
files. Also a TCP/IP service provider that trans- 
lates partial names into full names for IP addres- 
ses for machines and users. 


Department of Defense Makes a $10 billion com- 
pany like DEC look like your local ACE hardware 
store. 


Digital Operating System Microsoft operating 
system for IBM/PCs. 


Digital Operating System/Virtual Storage Ex- 
tended An IBM operating system used on 370 
architecture mainframes. 


Dots perinch A measure of the resolution of 
printers or scanners. 
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DQS 


DSA 


DSRI 


DSRVB 


DSS 


DSV11 


DTE 


DTF 


DU 


dX 


E.163 


Easynet 
EBCDIC 


Distributed Queueing Service A DEC software 
product that allows print files submitted to a 
local queue to be automatically sent to a remote 
queue. 


Digital Storage Architecture DEC architecture 
for mass storage devices and controllers. 


Digital Standard Relational Interface A DEC 
standard calling sequence for database applica- 
tions. Allows any DSRI-compatible user interface 
to access and DSRI-compatible data repository. 


DEC terminal server model number. 


Distributed system services A family of DEC 
software including the Digital Name Service 
(DNS) and the Distributed File Service (DFS). 


A high performance Q-bus synchronous com- 
munications board. 


Data terminal equipment An X.25 term referring 
to the interface to users’ equipment as opposed to 
the DCE interface to the network. 


Data transfer facility DEC software products 
that run in both VMS and IBM environments 
and permit the integration of both types of file 
systems from within the Digital Command Lan- 


guage. 


Data unit Part of the OSI File Transfer Access 
and Management (FTAM) protocols. 


DEC software product for transfer of WPS docu- 
ments into other formats. 


CCITT numbering scheme for public switched 
telephone networks. 


DEC’s internal communications network. 


Extended Binary Coded Decimal Interchange 
Code. A character code scheme used in IBM en- 
vironments. See ASCII. 


ECC 


EDE 


EDI 


EDT 


EGP 


ELK 


ELXSI 


EMA 


EMACS 


Email 


EMBOS 


EMS 
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Error-correcting code Feature of the Digital 
Storage Architecture used in error detection. 
Similar to a CRC. 


Electronic Document Exchange A DEC product 
that allows revisable form document transfer 
with DISOSS libraries. See also DDXF. EDE-W 
is a similar program for document interchange 
between Wang and DEC systems. 


Electronic data interchange A generic term refer- 
ring to the communication of information be- 
tween different organizations by computer in- 
stead of paper. For example, submitting a pur- 
chase order by modem instead of paper or fax. 


Standard DEC editor on the VMS operating sys- 
tem. 


Exterior Gateway Protocol A means for updating 
routing tables in the Internet environment. 


External Link Interface A programming library 
that allows an application to link to a Videotex 
(VTX) system on a remote DECnet node. 


Manufacturer of a parallel processing minicom- 
puter that has a variety of DEC emulation tools. 


Enterprise Management Architecture A DEC ar- 
chitecture for network management user inter- 
faces that can work with multiple displays and 
protocols. 


An extensible editor developed at M.I.T. based on 
the LISP programming language. 


Electronic mail Software/networks that allow 
the exchange of messages between users. 


Elxsi message-based Operating System Opera- 
ting system for the Elxsi, on top of which a 
variety of Unix and VMS emulation operating 
systems can run. 


Elxsi’s VMS emulator. 
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end node 


EOF 


ERCO 


Ethernet 


ETHERnim 


F.300 


FADU 


FAL 


FDDI 


FFT 


A DECnet term referring to a member of the net- 
work that can do everything but route packets 
through on behalf of other nodes. Ultrix, MS- 
DOS, and _ third-party implementations of 
DECnet are all end nodes. 


End of file A mark that tells the file system that 
it has reached the end of a file. 


Entry rules control object Provides validation 
checks for the OSI virtual terminal service in 
field mode. 


A data link protocol jointly developed by Intel, 
Xerox, and DEC and subsequently adopted by the 
IEEE as a standard. Several upper layer 
protocols, including DECnet, TCP/IP, and XNS, 
use the Ethernet as an underlying transport 
mechanism. Ethernet is to be contrasted with 
other data link protocols such as the token ring, 
DDCMP, or SDLC. 


Ethernet Network Integrity Monitor A DEC 
product for monitoring Ethernets. 


A set of CCITT recommendations for Videotex 
systems. 


File access data unit The unit of access in the 
OSI FTAM service. 


File Access Listener A process invoked across the 
network by a user trying to access data on nonlo- 
cal systems. A FAL is a DAP-speaking process 
invoked by the Record Management Services on 
the local node. 


Fiber Distributed Data Interface A 100-mbps 
fiber optic local area network standard based on 
the token ring. 


Final form text A version of IBM’s Document 
Content Architecture (DCA). 


field 


FLFMD 


frame 


FTAM 


ETP 


full-duplex 


Gandalf 


GAP 


Gateway 
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A term used in designing forms-based systems 
such as database applications. A field is a por- 
tion of the screen used for data input which is 
automatically mapped to a variable. The field 
may have attributes such as reverse video or 
default values. 


Function Interpreters for Function Management 
Data IBM’s presentation layer protocol for SNA. 


A series of bytes of data encapsulated with a 
header. The data link layer sends frames of data 
back and forth. “Frame” is often used interchan- 
gably with “packet,” although technically a pack- 
et refers to data from the network layer of the 
protocol stack. A packet is thus usually con- 
tained inside of a frame. 


File Transfer, Access and Management The OSI 
application layer service that provides access to 
virtual file stores on foreign systems. Similar to 
the DNA DAP protocols in purpose. 


File transfer protocol An upper-layer TCP/IP ser- 
vice used in the Arpanet implementation for the 
copying of files across the network. 


A data communications term that indicates that 
both ends of a communications link can transmit 
simultaneously. Contrasted with half-duplex 
where only one side can transmit at one time. 


A manufacturer of communications equipment in- 
cluding data switches. 


Gateway Access Protocol A protocol used by ap- 
plications software to access DECnet Gateways. 
The 3270 access routine, for example, would use 
GAP to access an SNA Gateway. 


There are two somewhat conflicting definitions of 
gateway, both used in networking. In the 
general sense, a gateway is a computer that con- 
nects two different networks together. Usually, 
this means two different kinds of networks such 
as SNA and DECnet. In TCP/IP terminology, 
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Gbytes 
GGP 


GM 


GOSIP 


granularity 


H4000 


half-duplex 


HASP 


Hewlett Packard 


HDLC 


as SNA and DECnet. In TCP/IP terminology, 
however, a gateway connects two separately ad- 
ministered subnetworks, which may or may not 
be running the same networking protocols. 


Gigabytes One billions bytes of data. 


Gateway to Gateway Protocol An interior 
protocol in TCP/IP similar in functionality to RIP. 


General Motors Primary supporter of the 
Manufacturing Automation Protocol (MAP). 
They also make cars. 


Government OSI Protocols U.S. government ver- 
sion of the international OSI standards. 


A term used in lock managers on an operating 
system. When the lock manager locks an entire 
file, this is locking with course granularity. 
When the lock manager locks a single record, 
this is fine granularity. Granularity is one of the 
factors that influences the performance of a par- 
ticular application, such as a DBMS. 


DEC’s baseband Ethernet transceiver. 
See full-duplex. 


Houston Automatic Spooling Program One of the 
original implementations of the remote job entry 
function on IBM equipment. Still used as a com- 
mon denominator, in conjunction with bisync, for 
RJE functions. 


Makers of a wide range of equipment that com- 
petes with or complements the DEC product line, 
including laser printers and minicomputers. 


High-level data link control International Stand- 
ard Organization’s data link protocol. Used in 
OSI and X.25 networks. Alternative protocols in- 
clude SDLC in the IBM networks or DDCMP in 
the DEC networks. 


hop 


HSC 


IBM 


ICMP 


IDI 


IEEE 


IDMS 


IMS 


Ingres 


Interleaf 


Interlink 
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A term used in DECnet routing calculations. A 
hop is one data link. A path to the final destina- 
tion on a DECnet is a series of hops away from 
the origin. Each hop has a cost associated with 
it, allowing the calculation of the least cost path. 


Hierarchical Storage Controller Stand-alone disk 
and tape controller used in clusters using the CI 
bus. The HSC is actually a modified PDP com- 
puter that has been optimized as a mass storage 
controller. 


International Business Machines Corporation 
Big. 


Internet Control Message Protocol Protocol used 
by the IP layer of TCP/IP for exchanging routing 
control messages. 


Initial domain identifier Part of an OSI address. 
Goes after the authority and format identifiers. 
For example, the IDI for a telephone address 
might be the country code. 


Institute of Electronic and Electrical En- 
gineers A leading standard-setting group in the 
United States. IEEE 488 is a popular standard 
for real-time data collection. IEEE 802 is the 
standard for various types of local area networks. 


Cullinet’s database management system for IBM 
systems. 


Information Management System Database 
management software from I.B.M. based on the 
hierarchical data management model. 


A popular relational database management sys- 
tem that runs on a variety of operating system 
platforms. 


A desktop publishing program that runs on 
VAXstations and Sun workstations. 


A manufacturer of SNA gateways. 
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Internet 


1/O 


IOP 


IP 


IPDS 


IPM 


IP/TCP 


IRDS 


ISAM 


ISDN 


ISO 


A collection of networks with a common routing 
backbone. Encompasses public networks such as 
NSFnet and private networks such as those at 
various universities. Also refers to the Internet 
Protocols that are part of TCP/IP and are used 
for routing data in the Internet. 


Input/output Generic term for transfer of data 
from main memory to either a disk drive, ter- 
minal, printer, or other device. 


Input/output processor Term used by Unix- 
based minicomputer manufacturers to refer to 
the I/O subsystems. 


Internet Protocol Layer 3 of the TCP/IP network 
protocols. 


Intelligent Printer Data Stream A component of 
IBM’s System Application Architecture (SAA). 


Interpersonal messaging service The part of the 
X.400 protocols that defines what the header of a 
message looks like. The message transfer service 
(MTS) then defines what the envelope that the 
message goes in looks like. 


Software product sold by the Wollongong Group. 
Allows VMS nodes to participate in TCP/IP net- 
works. A similar product is sold by Excelan. 


Information Resources Dictionary System An 
ANSI and ISO standard for data dictionaries. 


Indexed sequential access method A file structure 
that allows random access to data via an index 
and then sequential access to data after that. 


Integrated Services Digital Network A new inter- 
national communications standard that allows 
the integration of voice and data on a common 
transport mechanism. 


International Standards Organization Interna-- 
tional standard making body responsible for the 
OSI network standards and the ISO reference 
model. 


ISPF 


JCL 


JES 


JTM 


Kbps 


Kbytes 


Kermit 


kernel 


kerning 


LA100 


LAN 


LAP 
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Interactive System Productivity Facility An IBM 
product that runs on the TSO and CMS user en- 
vironments. ISPF provides a series of menus 
(dialogs) for use on a 3270 terminal that allow 
the user to bypass a command language interface 
to the operating system. 


Job Control Language Language used for batch 
processing on IBM mainframes. 


Job Entry Subsystem Types of processes on IBM 
mainframes that accept JCL. 


Job transfer and manipulation An OSI layer 7 
standard similar in function to a remote job entry 
(RJE) service. 


Kilobits per second Thousands of bits per second. 
Kilobytes Thousands of bytes of information. 


A popular file transfer protocol developed by 
Columbia University. Because Kermit runs in 
most operating environments, it provides an easy 
method of file transfer. 


A term used in operating systems. The kernel 
shields the low-level functioning of the operating 
system from high-level interfaces, such as user 
shells. 


A term used in typography which refers to the 
process of putting variable-size spaces between 
letters and words to produce an even alignment. 


A DEC dot matrix printer commonly found in 
machine rooms as console printers. 


Local area network Usually refers to Ethernet or 
token ring networks. 


Link access protocol A protocol for accessing a 
data link. Examples are LAP B used in the X.25 
environment and LAP D used in the ISDN en- 
vironment. 
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LAT 


LAVC 


LLC 


LNO3 


Logical name 


LPS40 


LSP 


LTM 


Local area transport A proprietary DEC ar- 
chitecture for terminal servers on Ethernet net- 
works designed to conserve bandwidth and off- 
load processing from hosts. 


Local Area VAX Cluster An adaptation of the 
System Communication Architecture (SCA) to 
run over the Ethernet instead of a CI bus. Used 
to enable MicroVAXs to operate as diskless 
nodes. 


Logical link control A term used in the IEEE 
local area network model. The logical link con- 
trol layer presents a uniform interface to the 
user of the data link service, usually a network 
layer. Underneath the LLC sublayer of the data 
link layer is a media access control sublayer. 
The MAC sublayer is responsible for taking a 
packet of data from the LLC and submitting it to 
the particular data link being used (such as 
Ethernet or token ring). 


DEC’s first 8 pages-per-minute laser printer. 
LNO3 is a proprietary language that has been su- 
perceded by the Scriptprinter, which uses the 
same engine and the Postscript page description 
language. 


A Digital Command Language feature which al- 
lows the logical naming of devices, permitting a 
layer of separation between the physical con- 
figuration of a system and the logical view seen 
by the user process. Similar to the Unix concept 
of an environmental variable. 


DEC’s 40-page-per-minute laser printer. Uses 
the Postscript page description language. 


Link state packet Routing control information 
message exchanged in a Phase V DECnet. 


LAN Traffic Monitor DEC software that uses a 
LAN Bridge 100 to monitor an Ethernet network. 


LU 


LU6.2 
MAC 


mail-11 


mailbox 


Mailbus 


MAP 


MB 
MBps 
mbps 
Mbytes 
MC68000 


MCI 
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Logical unit An IBM term in SNA which refers 
to a software or microcode program that uses the 
network. For example, a terminal connected to a 
3274 cluster controller is represented by a LU2 
on that cluster controller. 


See APPC. 


Media access control A communications term 
referring to the method of controlling access to a 
broadcast media, such as an Ethernet. The 
Ethernet uses CSMA/CD as a MAC-layer 
protocol. See also LLC. 


The original mail routing protocol used on VMS 
mail. Mailbus is a more modern routing ar- 
chitecture. 


A VMS concept used for interprocess communica- 
tion. Processes leave messages for each other in 
a mailbox. 


A DEC architecture which provides a common 
message-handling system on a DECnet. 


Manufacturing Automation Protocol An OSI-re- 
lated application sponsored by General Motors 
and endorsed by a great many users and ven- 
dors. 


Megabytes Million bytes of information. 
million bytes per second 

million bits per second 

Megabytes million bytes of information. 


A series of CPU chips manufactured by Motorola. 
These form the basis for many Unix-based 
workstations, including the MAC II and the Sun 
3 series. 


Long distance telephone company. 
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MEN 


MHS 


MICE 


MicroVAX 


Minitel 


MIPS 


MLAL 
MMS 


Modem 


MONITOR 


Management event notification Part of DECnet 
Phase V network management. Used for sending 
information about events across the network. 
See MICE. 


Message-handling system A system of protocols, 
such as X.400, used to exchange messages, such 
as electronic mail. 


Management information, control, and exchange 
A DECnet Phase V network management 
protocol. See MEN. 


A series of DEC processors using the Q-bus and 
competing in the workstation market with Sun 
and Apollo. 


A French terminal used for Videotex applica- 
tions. 


Million instructions per second A measure of 
CPU processing power. Different machine ar- 
chitectures use different instruction sets, so com- 
parisons of MIPS across products is highly mis- 
leading. MIPS also do not take into account the 
mix of other resources such as bus speeds, I/O 
processors, disk drive throughput, main memory, 
network controllers and other components of a 
system. 


Multiletter acronym listing 


Manufacturing messaging service Part of the 
MAP protocols used for communicating with 
robots, programmable controllers, and other 
devices. 


Modulator/demodulator A device that takes 
digital data from a computer and encodes it in 
analog form for transmission over a phone line. 
Modems are also used to connect computers to an 
analog broadband system. 


A VMS tool used to examine the current status of 
a system. 


MOP 


MS-DOS 


MSCP 


MTA 


MTS 


Multicasting 


Multiplex 


multipoint 
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Maintenance Operation Protocol A DECnet 
protocol used to efficiently download large files. 
Used for downline loading of the operating sys- 
tem for one component from another system. 


Microsoft - Digital Operating System Microsoft’s 
version of PC-DOS. 


Mass Storage Control Protocol The protocol used 
by HSC storage controllers to communicate with 
device drivers on the VAXs in a cluster. 


Message transfer agent An X.400 term referring 
to the collections of network members responsible 
for transferring messages. The final MTA 
delivers the message to a user agent which is 
concerned with reading, editing, and other types 
of interaction with the end user. 


Message transfer service The X.400 protocols 
that govern the exchange of envelopes of informa- 
tion. The IPMS defines the content of the en- 
velope. 


A term used in Ethernet addressing. A multicast 
address is a group address that is meant for a 
certain subset of users on the Ethernet. LAT 
nodes communicate their current status with 
each other using a multicast address. To be con- 
trasted with a broadcast address which is 
received by all users on the Ethernet. 


A software product made by Network Innovations 
(owned by Apple) that retrieves information from 
a variety of VAX database packages and trans- 
lates it into a variety of different PC formats. 


A data link layer concept in which multiple nodes 
share a common physical media. In a multipoint 
situation, a single node is the controller of the 
line and polls all tributaries periodically to see if 
they wish to send data. This is in contrast to 
multiaccess media like Ethernet where any node 
may send without permission. 
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MUXserver 


MVS/TSO 


NAK 


namespace 


NAU 


NCP 


ND 


NETACP 


Netbios 


NETDRIVER 


A DEC product that combines a multiplexer and 
a terminal server in one device. Allows remote 
multiplexed traffic to access LAT-based services. 


Multiple virtual storage/time sharing option 

MVS is an IBM operating system. TSO is the 
interactive subsystem, as opposed to a system 
like JES used for batch processing. 


Negative acknowledgment Response to noneceipt 
or receipt of a corrupt packet of information. 


A term used in DEC’s Distibuted Name Server 
which refers to the collection of all names on the 
network. The namespace is then distributed 
among multiple clearinghouses. 


Network addressable unit The boundary of an 
IBM SNA network. Logical and physical units 
are examples of NAUs. 


Network Control Program A DEC user interface 
to the network management layer of the Digital 
Network Architecture. 


NetDisk A Sun protocol for loading a raw disk 
over the network, similar in function to DEC’s 
MOP protocols. 


Network ancillary control process A type of VMS 
process that provides the link between the user 
of the network and the I/O drivers 
(NETDRIVER). 


Network basic input/output system Used in DOS 
as the interface to the network for accessing in- 
formation. Similar in function to the DNA DAP 
protocols. 


A VMS process that provides read and write ser- 
vices over the network for DECnet applications. 
NETDRIVER would then communicate with a 
physical driver that used Ethernet, DDCMP, CI, 
or another supported data link protocol. 


NeWS 


NEXT 


NFS 


NFT 


NIC 


NICE 


NML 


node 


nonrouting node 
Novell 
NPS 


NPSI 
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Network Extensible Window System A window- 
ing environment from Sun Microsystems based 
on the Postscript language and a proprietary 
window control protocol. 


Computer company founded by Steve Jobs, 
formerly of Apple. 


Network File System An extension to TCP/IP 
developed by Sun Microsystems and licensed free 
of charge. NFS allows files on remote nodes of a 
network to appear locally connected. 


Network file transfer An interactive utility that 
gives access to remote data using the DAP 
protocols. 


Network Information Center A facility located at 
the Stanford Research Institute that administers 
Internet addresses. 


Network Information and Control Exchange A 
DECnet protocol used for the exchange of net- 
work management information. 


Network Management Listener A VMS process 
that communicates with a network management 
interface on another node to provide information 
about the local node. 


A member of a network. A VAX is a node on a 
DECnet. A PC is sometimes a node on the net- 
work and sometimes it just emulates a terminal 
and thus is not a node. 


See end node. 
Makers of PC-based local area networks. 


NMCC protocol server A portion of the NMCC 
software that interfaces to the network. 


Network Packet Switching Interface A type of 
IBM software that allows SNA data to be carried 
over an X.25 network to another SNA environ- 
ment. 
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NSFnet 


NSP 


NSUID 


OA 


OEM 


O/R Address 


OS/2 
OSAK 


OSI 


packet 


PAD 


National Science Foundation Network An NSF- 
funded network to link researchers to computing 
facilities. 


Network Services Protocol A protocol used at the 
end-to-end communication layer of the Digital 
Network Architecture to assure reliable com- 
munications. 


Namespace unique identifier See namespace. It 
is possible (though somewhat unusual) to have 
multiple DNS namespaces on a single network. 


Office automation Whatever’s in Datamation 
this month. 


Original equipment manufacturer Company that 
sells equipment which is embedded in another 
company’s products. The other company is 
known as a value-added reseller (VAR) of the 
product. 


Originator /recipient address A valid X.400 ad- 
dress. 


IBM’s replacement for DOS. 


OSI Applications Kernel A set of program 
libraries sold by DEC as the interface to layer 5 
of the OSI model. 


Open Systems Interconnect The International 
Standards Organization’s implementation of the 
ISO reference model. 


A general term used in networking to refer to a 
message sent to a peer entity in the network. 


Packet assembler/disassembler A piece of 
hardware used in packet switched networks to 
allow asynchronous terminals to participate in 
the network. 


Paging 


PAM 


PAR 


PBX 


PC 


PC-DOS 


PCSA 


PDL 


PDP 


PDS 


Phase IV 
PDU 
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A memory management technique in a virtual 
memory operating system. Only a few parts 
(pages) of a program are actually in memory. 
When a new part is needed, it is paged into 
memory. 


Protocol assist module A piece of hardware on a 
DECSA to provide higher performance for 
protocol processing. 


Positive acknowledgment retransmit A method of 
assuring reliable communications used by the 
DDCMP data link protocol. 


Private branch exchange A sophisticated switch 
used to route telephone calls and data from in- 
coming trunk lines to the appropriate user’s 
desk. Value-added functions include call forward- 
ing and voice mail systems. 


Personal computer IBM series of computers or 
clones. 


Personal Computer - Digital Operating System 
IBM’s version of Microsoft’s operating system. 


Personal Computing Systems Architecture 
DEC Architecture for PC-DOS systems, including 
the DECnet/DOS software. 


Page description language Postscript is an ex- 
ample of a PDL. 


Programmable data processor A series of Q-bus- 
based 16-bit minicomputers manufactured by 
DEC. 


Premises Distribution System AT&T cabling sys- 
tem. 


The current phase of DECnet. 


Protocol data unit A packet of information con- 
forming to a protocol, such as a data link protocol 
(e.g., Ethernet) or a network layer protocol (e.g., 
Connection Oriented Network Service). Usually 
used in the context of the OSI architecture but 
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P/FM 


PHONE 


PID 


portal 


Postscript 


ppm 


PrE 


PRMD 


PROFS 


PS profiles 


PSI 


PSN 


the concept applies to any layered network ar- 
chitecture. 


PBX/Facilties Management DEC software for 
managing PBX traffic. 


A VMS program that allows interactive two way 
conversations over a DECnet. 


Process identification number Used to identify 
each process running on an operating system. 
The VMS lexical function F$PID returns the 
value of PID. 


A term used in Ethernet protocols. There may be 
several different users of the Ethernet service, 
such as LAT, DNA, and TCP/IP. Each of these 
users is given a portal, or identification number, 
in the portal database. Incoming packets are 
then distributed to the appropriate portal. 


A page description language developed by Adobe 
Systems. Widely adopted by many vendors as a 
de facto standard. 


Pages per minute Rating measure for laser 
printers. 


Printer emulation DEC SNA access routine 
which allows a VAX to emulate an IBM printer. 


Private management domain An X.400 domain. 
See ADMD. 


IBM office automation system that runs on the 
VM operating system. 


Presentation services profiles An SNA term used 
to allow two NAUs to negotiate an acceptable 
subset of presentation functions they can both 
support. 


Packet-switch interface DEC software to allow a 
VAX to participate in an X.25 network. 


Packet switched network An X.25 network. 


PTT 


PU 


Q-bus 


QIO 


QOS 


RAM 


RARP 


rep 


Rdb 


ReGis 


RFT 


RGB 


RIP 
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Poste Téléphone et Télégraphe A government 
provider of communications functions in most 
European countries. 


Physical unit An SNA term used to refer to dif- 
ferent types of hardware in the network. A 3274 
cluster controller is a PU type 2 (PU2). 


The peripheral bus used on MicroVAX and PDP 
computers. 


Queue input/output Device-dependent layer in 
the VMS operating system. See RMS. 


Quality of service A series of negotiable 
parameters in X.25 and OSI network implemena- 
tions. 


Random access memory Dynamic memory, some- 
times known as main memory or core. 


Reverse Address Resolution Protocol A TCP/IP 
protocol which provides the reverse function of 
ARP. Used by diskless nodes when they first ini- 
tialize to find their Internet address. 


Remote copy program An upper layer TCP/IP 
service found in the Berkeley Unix implementa- 
tion for copying files. See FTP for the Arpanet 
equivalent. 


DEC’s relational database management system. 


Remote graphics instruction set A set of DEC 
protocols used in the VT240 and 241 graphics 
terminals. 


Revisable form text A version of IBM’s Document 
Content Architecture. 


Red, green, blue A method of representing colors 
as a mix of the three primary colors. 


Routing Information Protocol An alternative to 
EGP used for updating routing tables in the In- 
ternet environment. 
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RISC 


RJ11 


RJE 


rlogin 


RMS 


root 


rotary 


Routers 


RPC 


Reduced instruction set computer Generic name 
for CPUs that use a simpler instruction set than 
more traditional designs. Examples are the IBM 
PC/RT, Pyramid minicomputers, and the Sun 4 
(SPARC) Workstations. 


Standard modular jack developed by AT&T. 
Used for telephones and data communications. 
Being replaced by the RJ45 which is the same 
size but has more wires. 


Remote job entry Facility for submitting a job to 
a computer for execution. Card readers were 
early RJE stations. Usually means software that 
emulates RJE stations. 


Remote log-in Berkeley TCP/IP command to log 
onto a remote node. 


Record management services A common I/O in- 
terface for VMS used for access to local data via 
QIO calls and remote data via the DAP protocol. 


Unix superuser. The one account on a Unix sys- 
tem that has privileged access. 


An example of a rotary is when several outgoing 
lines are available for a dial-out service. Rather 
than make the user ask for each line by name, a 
rotary service connects the user to the first avail- 
able line. A rotary is thus multiple instances of 
an all-accessible service using one address. The 
service provider intercepts all requests for that 
address and farms them out to a specific address. 


Dedicated hardware used to route traffic on a 
network. The alternative is to use a portion of a 
general purpose system such as a VAX. 


Remote procedure call Part of the Network File 
System. This is the layer 5 (session layer) ser- 
vices built on top of TCP/IP. 


RS-232-C 


RSM 


RSTS 


RSX 


RT/PC 


RU 


SA482 
SAA 


SAF 


SASE 


SCA 


Scriptprinter 
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A physical interface standard, used frequently for 
connecting asynchronous devices such as ter- 
minals. Developed by the Electronic Industries 
Association to define the electrical and mechani- 
cal link between a DTE and a DCE. 


Remote Systems Manager DEC software for 
managing remote MicroVAX computers. 


Resource-sharing timesharing system PDP-based 
operating system. 


Yet another PDP-based operating system. VMS 
systems running in compatibility mode are able 
to execute RSX-executable images. 


IBM 32-bit workstation based on a RISC ar- 
chitecture. 


Request unit A part of IBM’s SNA architecture. 
A series of request units are sent from one ses- 
sion participant to the other; they are then 
processed by upper layers of the protocol stack. 


DEC disk cluster with 2.5 Gbyte of capacity. 


Systems Application Architecture IBM Architec- 
ture to present common user, communications, 
and programming interfaces across multiple 
hardware platforms and operating systems. 


System Authorization Facility A family of IBM 
security products. 


Specific application service element Application 
layer concept in the OSI network architecture. 
Refers to special purpose services such as the job 
transfer and manipulation (JTM) facility. 


System Communication Architecture The DEC 
architecture for Clusters. 


DEC’s Postscript printer. Uses the same engine 
as the LNO3 laser printer but with a different 
controller board. 
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SCS 


SCSI 


SDLC 
SER 


session 


shell 


SIXEL 


skulker 


slot 


Smartstar 


System communication services Software _ ser- 
vices used in a VAX Cluster to provide internode 
communication. SCS is the lowest level of the 
System Communication Architecture. 


Small computer standard interface Pronounced 
“scuzzy.” A standard for connecting disk drives to 
disk controllers, used typically in small multi- 
user computers. Third party vendors sell SCSI 
boards for MicroVAXs. 


Synchronous data link control IBM’s data link 
protocol used in SNA networks. 


Satellite Equipment Room One part of the 
DECconnect cabling system. 


Networking term used to refer to the logical 
stream of data flowing between two programs 
communicating over a network. Note that there 
are usually many different sessions originating 
from one particular node of a network. 


A term that usually refers to the user interface 
on an operating system. On Unix systems, the C 
shell or the Bourne shell are the primary user 
interfaces. Contrasts with the kernel, which in- 
teracts with the computer at low levels. 


A standard format used for bit-mapped images. 
Complements ReGIS, which is a DEC format for 
line-oriented images. 


A term used in DEC’s distributed name service. 
A skulker is a background process which assures 
that all replicas of a portion of the namespace 
are consistent with the master portion. 


The upper layer of the Local Area Transport Ar- 
chitecture. A slot holds data from one particular 
user. Several slots are contained in a LAT pack- 
et. 


A DSRI-compatible application development en- 
vironment made by Signal Technology. 


SMP 


SMTP 


SNA 


SNADS 


Sniffer 


SOH 


SPARC 


SQL 


SS7 


SSCP 


star coupler 


STE 
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Symmetric multiprocessor Term used by DEC for 
true parallel processing in version V of VMS. 


Standard Mail Transfer Protocol The TCP/IP 
protocol for a message handling system. 


Systems Network Architecture IBM network ar- 
chitecture. 


SNA distribution services An architecture used 
for transferring messages in an SNA environ- 
ment, similar to X.400. 


A network analyzer made by Network General. 
The Sniffer was used to produce the screen 
dumps of network packets in this book. 


Start of header The beginning of a DDCMP mes- 
sage. 


Scalable Processor Architecture A reduced _ in- 
struction set (RISC) processor developed by Sun 
and licensed by several vendors including AT&T 
and Texas Instruments. Used in the Sun 4 fami- 
ly of workstations. 


Structured query language ANSI standard data 
manipulation language used in most relational 
database systems. 


Signalling System 7 Protocol related to ISDN. 
Directs how the interior of an ISDN network is 
managed. 


System services control point A network addres- 
sable unit in IBM’s SNA architecture. Resides on 
a mainframe and is the central point for that 
domain of an SNA network. 


Device used to connect different nodes of a VAX 
Cluster that use the CI bus. 


Signalling terminal exchange Equipment in an 
X.25 network that forms the boundary of a net- 
work. Communication between different X.25 
management domains is between STEs using the 
X.75 protocols. 
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subnet 


Sun 
Microsystems 


SVID 


Sybase 


symbiont 


SYSS$COMMAND 


SYSSERROR 


SYSSINPUT 


SYS$LOGIN 


SYSSOUTPUT 


A term used to denote any networking technology 
that makes all nodes connected to it appear to be 
one hop away. In other words, the user of the 
subnet can communicate directly to all other 
nodes on the subnet. A subnet could be X.25, 
Ethernet, a token ring, ISDN, or a point-to- point 
link. A collection of subnets, together with a 
routing or network layer, combine to form a net- 
work. 


Manufacturer of Unix-based workstations. 


System V interface definition AT&T sponsored 
definition used to determine the compatibility of 
different implementations of System V. 


Manufacturer of a hybrid database system which 
uses general-purpose hardware such as a VAX or 
Sun Workstation and optimizes it for relational 
database operations. 


Symbiosis is the bringing together two different 
worlds. A symbiont is a VMS process that takes 
disk files and prepares them for a printer. 


A VMS logical name that points to the device 
that will be used to input commands for the Digi- 
tal Command Language. Points to a terminal 
device (i.e., tta0:) for an interactive session or a 
command file for a batch job. 


A VMS logical name that points to the device 
used to output error messages for the current 
user. 


A VMS logical name that points to the device 
used to input data (as opposed to commands) for 
the current user. 


A VMS logical name that points to the default 
log-in directory for the current user. 


A VMS logical name that points to the device 
used to output results (as opposed to errors) for 
the current user. 


SYS$PRINT 


SYS$SYSTEM 


SYSGEN 


T1 


TCP/IP 


Teamdata 


Telenet 


TELNET 


terrabyte 
ThinWire 


TK50 


TPDU 


TSAP 


TTRT 
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A VMS logical name that points to the default 
print queue for the current user. 


A VMS logical name that points to the location of 
system executable images. 


A program in VMS used to alter system-wide 
parameters such as AWSTIME. 


1.544 mbps communications line provided by long 
distance common carriers. 


Transmission Control Protocol / Internet Protocol 
Department of Defense sponsored networking 
protocol, used frequently in Unix environments. 


DEC-developed user interface for DSRI com- 
patible relational data bases. 


Packet switched network service offered by GTE. 


Upper-layer TCP/IP service for Arpanet im- 
plementations. Allows users to log onto remote 
nodes. 


One trillion bytes (1,000,000,000,000) 


Thinner, and cheaper, version of baseband coax 
cable used for Ethernet networks. Also called 
CheaperNet. 


DEC tape cartridge which holds 95 Mbytes of in- 
formation. 


Transport protocol data unit A packet of infor- 
mation exchanged between two tranport layer en- 
tities in an OSI network. See PDU. 


Transport service access point Each layer of the 
OSI network has a series of service access points, 
sometimes known as service primitives, that 
clearly define the functions that that layer can 
perform on behalf of clients. 


Target token rotation time A term used in FDDI 
to set performance parameters. The TITRT ser- 
ves aS a measure of expected delay and is used, 
among other things, to set time-out parameters. 
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TTY 


token bus 


token ring 


transceiver 


TransLAN 


tuple 


twisted pair 


Tymnet 


UDP 


UIC 


Teletype A line-oriented terminal. 


An alternative to token ring and Ethernet local 
area networks. Used in the MAP protocols. The 
token bus uses a multiple access protocol, but the 
device that “owns” the token is the only one that 
can send data. 


A local area network protocol in which computers 
are connected together in a ring. A node waits 
until a token is passed around the ring, at which 
point it may send data. When it has finished 
sending it releases the token and passes it to the 
next node. See FDDI. 


A term used in Ethernet networks. The 
transceiver is the hardware device that connects 
to the Ethernet media, often a piece of coax 
cable. The transceiver is then connected to an 
Ethernet controller on the host system. 


A wide area extended Ethernet bridge manufac- 
tured by Vitalink. 


A term used in relational database systems. A 
tuple is the equivalent of a record in a file 
management system and corresonds to one row 
of data in a table. 


A pair of wires (or several pairs of wires) such as 
is used to connect telephones to distribution 
panels. Twisted pair is also being used as a 
physical transmission media for Ethernet, token 
ring, and other forms of data links. 


Public packet-switched network based on X.25 
owned by McDonnell Douglas. 


User Datagram Protocol Used in TCP/IP as an 
alternative to TCP for unacknowledged 
datagrams. 


User identification code VMS code used to uni- 
quely identify every user on the system. 


UIL 


Ultrix 
Unibus 


Unix 


Usenet 


UUCP 


VAX 11/780 


VAX 6200 


VAX 8600 
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User interface language A DECwindows concept 
that allows the user interface to be modified for 
different countries without modifying the source 
code of the program. 


DEC’s version of 4.3BSD Unix. 


A peripheral bus used on 11/780 and 8600 VAX 
processors. 


Operating system developed and trademarked by 
American Telephone and Telegraph. Unix is a 
pun on the Multics operating system. 


Network of Unix users. This is a somewhat in- 
formal network of loosely coupled nodes that 
agree to exchange information in the form of 
electronic mail and a bulletin board. 


Unix-to-Unix copy program The standard Unix 
utility used to exchange information between any 
two Unix nodes. Used as the basis for Usenet. 


A CCITT standard for the interconnection of 
DTE and DCE equipment. 


CCITT standard for 4.8- to 9.6-kbps modems. 


CCITT physical interface standard for high-speed 
data transmission. 


Value-added reseller Company that embeds 
another company’s products into a more sophisti- 
cated product. 


VTX applications service A library used _ to 
develop applications on DEC’s VTX software. 


Virtual address extension A hardware _ series 
made by DEC. 


A single Vax processing unit processor. Some- 
what equivalent to a one MIP computer. 


A series of VAX parallel processors with 1 to 6 
CPUs using the XMI bus. 


A 4-VPU computer. 
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VAX 8700 


VAX 8840 


VAX Clusters 


VAXeln 


VAXlink 


VAXmate 


VAXNotes 


VAXstations 


VIDA 


VIA 


VISTA 


Vitalink 


VM 


A 6-VPU computer that forms the basis for the 
Bi-bus-based VAX computers. 


A parallel processor with four 8700 CPUs. 
Roughly 24 VPU of power. 


DEC Clusters that operate on the CI bus rather 
than over the Ethernet. 


DEC real-time operating system. 


A family of products that allow access from a 
DSRI-compatible user interface to a series of 
IBM-based data repositories. 


DEC 80286-based PC/AT clone, with the addition 
of an Ethernet controller and a different key- 
board. 


DEC conferencing software. 


MicroVAX workstations with a 15-inch or 19-inch 
bit-mapped graphic screen and graphics co- 
processor. 


DEC DSRI product that allows access to Cullinet 
IDMS databases using any DSRI user interface. 


VAX Information Architecture A related set of 
software systems sold by DEC for data manage- 
ment systems. 


VTX Infobase Structure Tool and Assister Softw 
are package for maintaining VTX databases. 


Makers of the TransLAN wide area Ethernet 
bridge. 


Virtual machine An IBM operating system 
which permits guest operating systems, such as 
MVS, to reside on top of it. Usually used in con- 
junction with the CMS user interface. 


Virtual memory An operating system concept 
that refers to the address space of a program. A 
paging system maps virtual memory to the 
limited physical memory pages as needed. 


VMS 


VMS/SNA 


VSAM 


VT100 


VTAM 


VTX 
WAN 
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Virtual memory system A DEC proprietary 
operating system for VAX computers. 


DEC software that allows a VAX with the ap- 
propriate synchronous communications board to 
function as an SNA gateway. 


VAX OSI Applications Kernel DEC programming 
library for the OSI session layer. 


VAX OSI Transport Services DEC OSI software 
that implements layer 4 of the ISO reference 
model. 


Vax processing unit A DEC measure of process- 
ing power. The 11/780 is equivalent to one VPU. 
A VPU is roughly analogous to a MIP although 
these numbers cannot be compared across 
product lines because an instruction is different 
on each computer because of different instruction 
sets. 


Virtual sequential access method File organiza- 
tion method used in IBM environments for direct 
access files. Similar to ISAM (indexed sequential 
access method). 


Virtual terminal OSI application layer service to 
allow remote log-in to other nodes. Also a series 
of terminals, such as the DEC VT100 or VT241. 


A series of DEC terminals. The VT300 series is 
the current family of DEC terminals. VT100 and 
VT200 are a de facto industry standard, meaning 
that most software packages include terminal 
drivers for these types of terminals. 


Virtual Telecommunications Access Method A n 
IBM software system that provides the interface 
to an SNA network. 


Videotex DEC’s Videotex software package. 


Wide area network Sometimes also used to mean 
work area network or a small subnetwork for a 
work group. 
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Wollongong 
Group 


WORM 


WSDEFAULT 


WSEXTENT 


WSQUOTA 


X.3 


X.21 
X.21bis 


X.25 
X.28 


X.29 


X.75 


X.121 
X.400 
X.500 


XDR 


Makers of the IP/TCP software for VMS and a 
Unix emulator for VMS called Eunice. 


Write once/read many A type of optical disk that 
can be written locally, contrasted to CD-ROM 
disk. Also used for fishing. 


A VMS parameter that controls the size of a user 
working set. 


A VMS parameter that controls the size of exten- 
sions for a user working set. 


A VMS parameter that controls the quota of a 
user working set. 


CCITT standard for a packet assembler/disas- 
sembler (PAD). 


CCITT standard for circuit-switched networks. 


CCITT standard for connecting to public data 
networks using a V-series modem. 


CCITT standard for packet-switched networks. 


CCITT protocols for an asynchronous terminal to 
communicate with an X.3 PAD. 


CCITT protocols for a synchronous DTE (a host) 
to control and communicate with an X.3 PAD. 


CCITT standard for interconnecting separate 
X.25 networks. 


CCITT numbering plan for public data networks. 
CCITT standard for message-handling systems. 


Emerging CCITT standard for directories for 
X.400 networks. 


eXternal Data Representation A machine inde- 
pendent protocol for representing information 
used in the network file system (NFS). 


XI 


XID 


XMI 


Xmodem 


XNS 


XQP 


X.3 


X.21 


Yellow Pages 
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IBM product for using X.25 in a heterogeneous 
environment, as opposed to NPSI which uses 
X.25 as a transport mechanism for SNA. 


Exchange identification An HDLC frame used 
when a new node attaches to the physical 
medium. 


A 100-Mbps bus used to connect CPUs, BI buses 
and memory on the VAX 6200 series of parallel 
processors. 


A set of protocols used for error free file transfer 
Over voice grade lines. Similar to Kermit, 
Xmodem is used to transfer binary and ASCII 
files from different hosts that are not running a 
common set of networking protocols. 


Xerox Network System A set of upper layer 
(layers 3 and 4) protocols, typically used in con- 
junction with Ethernet. An alternative to 
DECnet or TCP/IP. 


Extended QIO processor A VMS process that 
receives requests for data. 


CCITT standard for interfacing asynchronous 
devices to X.25 networks. 


CCITT standard for circuit-switched networks. 
Often, a circuit is established using X.21, fol- 
lowed by X.25 traffic over the circuit. 


A set of services in the Network File System that 
propagate information out from masters to 
recipients. Used for the maintenance of system 
files on complex networks. 
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abstract syntax notation (ASN), 
330 

access messages, 63-64 

address resolution, 243-245 

Address Resolution Protocol 
(ARP), 244 

Advanced Program-to-Program 
Communication (APPC) 
function, 280 

application layer overview, 333 

Application Programming 
Interface (API), 293 

Arpanet, 254 

asynchronous system trap (AST) 
locking option, 66 

AT&T Premises Distribution 
System (PDS), 131 

attribute message, 63-66 

Authorization Entries, 76 

autoconfiguration, 320 

autonomous systems and Internet, 
251-253 

interior gateway protocols, 253 


baseband, 121 

Basic Rate Interface (BRD, 189 

basic services integration, 290-292 

Bzier curves, 401 

binary object sequence (BOS), 411, 
413 

border-crossing event, 382 

bracketing, 283 


Index 


bridge, 136-139 

brouters, 176 

bus, 32 

byte synchronization, 27—28 


CASE facilities, 333-336 

Census Automated Processing 
System (CAPS), 115-116 

Census Bureau Clustering case 
study, 115-116 

Cheapernet, 126 

child window, 371, 373 

CI bus hardware, 99-100 

clearinghouse, 73 

clerk, 75 

clipping paths, 401 

clip mask, 375 

closed user group (CUG), 187 

cluster overview, 97-99 

collision, 34 

command terminal protocol 
messages, 60 

Common Management 
Information Protocol (CMIP), 
232-233 

communication controller, 278-279 

Community Antenna TV (CATV), 
128 

connectionless network service, 
(CLNS), 316 

connection management, 103-104 

constraint set, 336-337 
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control message, 28-29 
Conversational Monitor System 
(CMS), 280 
Cray I/O Subsystem (IOS), 181 
creating and rendering paths, 
400-404 
cached user paths, 403-404 
graphics states, 401-404 
CTERM module, 58-59 
current transformation matrix 
(CTM), 398-400 


DAP Protocol, 69-70 
Data Access Protocols (DAP), 11, 
59-70 
configuration messages, 63-66 
control messages and data 
access, 66-67 
DAP operation, 67—70 
Data Circuit Terminating 
Equipment (DEC), 183 
Data Distributor, 298 
data link layer, 26 
data link support, 311-313 
DEC and HDLC, 313-314 
Data Terminal Equipment (DTE), 
183 
Data Transfer Facility, 294 
DDCMP data link products, 27-31 
link management, 30 
message exchange, 30-31 
DEC Communications Server 
(DECSA), 173 
DEC Local Network Interconnect 
(DELND), 124-127 
DEC messaging strategy, 360-363 
DECrouter, 167 
DEC Easynet, 194-197 
DECserver 500, 143-145 
DEC Station Adapter (DESTA), 
127-128 
DECwindows and X, 387-390 
user interface language files, 
390 


user interface standardization, 
388-390 
dedicated routers, 173 
default window manager, 384-385 
Defense Advanced Research 
Projects Agency (DARPA), 241 
DEMSA, 173 
designated router, 41 
Digital Data Communications 
Message Protocol (DDCMP), 9 
Digital Network Architecture, 9-11 
Digital Standard Relational 
Interface (DSRI), 296 
direct memory access (DMA), 89 
directors, 231 
Distributed File System, 76-79, 
108-109 
Distributed Queuing Service 
(DQS), 78-79 
distributed lock managers, 
104-108 
Distributed Naming Service, 70—76 
object attributes, 72—73 
replicas and partitions, 73-76 
Distributed Office Support System 
(DISOSS), 298 
distributed queuing systems, 
109-111 
DNA clones, 207-209 
DNA implementation on VMS, 
200-204 
DNA/SNA interconnection 
strategies, 285-289 
data switches, 289 
DECnet/SNA Gateway, 
285-286 
direct host connections, 
287-289 
third-party gateways, 
286-287 
Document Content Architecture, 
299 
Document Interchange 
Architecture, 299 
domain naming system, 256-258 


dynamically established data link 
(DED), 187 


Easynet, 197 
electromagnetic interference 
(EMI), 158 
Elexsi Message Based Operating 
System (EMBOS), 208 
Enterprise Management 
Architecture (EMA), 234 
Ethernet data link products, 31-37 
CSMA/CD media access 
control, 34 
Ethernet version 2.0, 35 
IEEEE 802.3 LANs, 35-37 
Ethernet standard, 6, 9 
events, 379-382 
exchange identification (XID) 
frame, 313 
extended Ethernets, 135-142 
automatic learning, 137 
multicast addresses, 140 
spanning tree algorithm, 
138-139 
types of bridges, 140-142 
Exterior Gateway Protocol (EGP), 
251 
External Data Representation 
(XDR), 268 
External Link Interface (ELK), 80 


facilities wiring: DEconnect, 
155-158 
file access data unit, 338-339 
File Access Listener (FAL), 67, 
206-207 
File Transfer Access Management 
(FTSM), 61 
file transfer and access, 336-341 
DEC FTAM software, 341 
flusher, 45 
focus event, 382 
fonts, 404—407 
bit map fonts, 406-407 
font caches, 407 
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fork operator, 410 
frame check sequence (FCS), 311 


Gateway Access Protocol (GAP), 
186 
Gateway-to-Gateway Protocol 
(GGP), 253 
go/no-go option, 63 
graphics context, 374-377 
graphics manipulations, 377-378 
cursors, 378 
regions and images, 378 
gstate, 402 


header, 5-6 

high-level data link control 
(HDLC), 311 

hints, 383 


icon, 368, 371 
images, 407-409 
halftones, 408-409 
Information Resources Dictionary 
System, (IRDS), 339 
Integrated Services Digital 
Network, (ISDN), 16 
integrating data access, 294-298 
database access, 296-298 
Interlink Network Controller, 
286-287 
International Standards 
Organization (ISO), 4 
Internet addresses, 243 
Internet Control Message Protocol 
(ICMP), 248-251 
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